BxbAsm

[jcfuller]

Same here with gcc.
James

Code: [Select]

int __stdcall jcftest17 (void);

int __stdcall jcftest17 (void)
{
  int      i;
  i= 17;
  return i;
}

and then no "c" in the protos.

Code: [Select]

;my c functions
 jcftest17 proto
 jcftest18 proto


[SteveA]

Okay, looks like you're on top of it.
I've never had this issue before.
Libs I've created in the past were used with C programs, so they just seemed to work.
This is the first time I've tried to use a C lib with asm.

Anyway, problem solved.
Now, back to building the Bxb routines to put in the lib.
Thanks

[jcfuller]

I really don't "do" c/c++. This is the actual Bcx code that produced the c.
James

Code: [Select]

$PRJ
$NOWIN
$NOMAIN
$ONEXIT "gcc -c $FILE$.c -m32"
Function jcftest17() As Integer stdcall
    Raw As Integer i
    i = 17
    Function = i
End Sub



[SteveA]

I really don't "do" c/c++.  This is the actual Bcx code that produced the c.

...ahh. Yes, that can be helpful.

[SteveA]

I'm getting some mixed results with JWasm when testing some code.
I'm using the same code I used with Masm and Masm32, but, I occasionally get "missing prototype" errors from standard C runtime functions.
I think it's partly because so many of the header (INC) files are missing from jwasm and I don't know what to replace them with.

I'm going to post on masm32, see what that turns up.

[SteveA]

I'm going over bxbasm source code with a fine tooth comb right now.
When I last revised the code, I made a considerable number of changes as to how variables were handled, which I now regret.
As one might expect, major changes to existing code have a tendancy of introducing new bugs.

The way I left it, it was trending towards a VB style of variable interface, which is really not very Bxbasic.
Also, since what I was working on was never quite completed, there are large holes in the program that need to be plugged.
I need to take it back to the roots and decide what I want the out-come to look like.

Known (actual) bugs:
1: multiple data types can be (erroneously) assigned to the same variable name,
   like:  abc = 123
          abc# = 99.9
          PRINT abc

   This should produce a parser error, (invalid data type), or, create two distinct variables.

2: no trap to guard against using reserved words as variable names,
   like:  test$ = "foobar"

   generates an assembler error.
   Originally, there was a mechanism in place (Hungarian notation) to guard against that happenning.
   For some reason, I removed that safeguard. Can't remember why tho'.

[John]

Hi Steve,

It's been almost a month since we heard from you last. How is the project going?


John

[SteveA]

Hi Steve,
It's been almost a month since we heard from you last. How is the project going?
John

Sorry for the delay in updates.
1) I've been quite busy, (seasonal thing),
2) I'm performing a complete rewrite of the variables parser-handler for bxbasm.

When I started looking at my original code for bxbasm, I could see that the way I parsed variables differed too greatly from the way bxbasic does at present. Not that there was anything wrong in the way I did it, it's just that I would like source script from one dialect to be compilable via the other. And that wasn't going to happen.
Over the years, bxbasic had grown and gone through many rewrites and bxbasm hadn't.
So, I'm bringing bxbasm up to the same level.
I'm not talking about cosmetic things, I'm talking about the core engine of the thing.

I'll try and be a little more conversant about the details of what's happening.

[SteveA]

Current update:
Well, I've been working away on Bxbasm.
I've done almost a complete rewrite of the way variables are processed.
The way I had left it, (years ago), just wasn't to my likeing at the present time.
As I've stated previously, when I last worked on it, it was looking more like VB.
I wanted to take it back to a simpler form. More QB like and most importantly, more Bxbasic like.

Right now, I'm testing all the functions and making sure it compiles, assembles and works as expected.
There have been a few glitches along the way that I have had to correct.
I have to say, it's much easier to write new, fresh code than it is to rework old code.
When reworking older code, you always seem to break other things along the way. That's to be expected.

Anyway, I'm running through all the test examples I've written and making tweaks along the way.
At the rate I'm progressing, I should have a test release ready in a week or two.

[John]

Steve,

Thanks for the update and good to hear you're making progress.

Should this topic be moved to the compiler section with a new thread title? I assume you're not using Ubx to get there.

John

[SteveA]

Should this topic be moved to the compiler section with a new thread title? I assume you're not using Ubx to get there.

Funny thing...,
I thought I had created a thread over there (compilers), but, I didn't see it.


edit:
my mistake...
I had a thread in interpreters.
Yes, I should have stated a thread in compilers.

[jcfuller]

Steve,
  Great to hear of your progress but isn't BxbAsm still a translator?
Basic source to assembler source then compiled to and exe by JWasm ??

James

[SteveA]

... but isn't BxbAsm still a translator?
Basic source to assembler source then compiled to and exe by JWasm ??

Very good point, James.
Yes, it is a translator.
However, I have found that there is a grey area there where translator fades to compiler (as it were).

In my opinion (and that is all it is) a true compiler would be one single program (both frontend and backend) that did everything from start to finish.
By that I mean, take the original source code (script) and generate the object code and ultimately link and create the finished executable.
All in one program.
However, no one actually does that.
As we are all quite aware, the compile process is a multi-step process.
I have found that in many cases, compiler creators borrow steps from other compilers.

I wish I had the time, financial resources and know-how, to just jump right in a do it, start to finish.
I've certainly read up enough on the subject.
At this point in time, I would simply like to produce the front-end and borrow someone elses mid-section and back-end.
Time will tell...

[John]

However, no one actually does that.

I disagree. I think OxygenBasic is a true compiler. (JIT is optional)

[aurel]

I think that Oxygen Basic is not 'true compiler' then JIT.Still exe depend on oxygen.dll
Oh yes ...
there is option with rtl and in this case there is no need for oxygen.dll.
oups i forget..