BxbAsm

[SteveA]

I disagree. I think OxygenBasic is a true compiler.

That may very well be the case.
I have not had the time to examine OxygenBasic, but, it does sound very interesting.
I am intrigued by it.

[aurel]

Hi Steve ...
Intrigue...
I found him very simple with clean code.
Hmmm i think that i forget little bit update OxyEdit

[Charles Pegge]

Just to clarify: Oxygen goes all the way down to machine code, without a token layer. Oxygen.dll contains both a compiler and a run-time library. By including an RTl32 or RTL64 with the source code, the binary can be made independent of Oxygen.dll

For the new year, I will be investigating possible emitters and translators by tapping off the compiler pipeline at various stages. (The devil is always in the detail )

Charles

[SteveA]

Update:
It's been over a week so I thought I'd better give an update.
First, I've been a bit under the weather for the past week, (cold/flu) whatever is going around.
I did manage to do some work on Bxbasm in spite of it.

I've been putting the current version of bxbasm thru some tests. I dug out my old samples and I'm testing each one and doing some fine tuning.
Funny, I was stuck for about three days trying to find a bug in the file I/O section.
It seemed to me that random file I/O was not working the way it was supposed to and producing so odd results.
I disected the code from beginning to end and could find nothing wrong.
As it turned out, the code was correct and the file I/O was working just as it was supposed to.
That's what happens when you try coding when you are sick.

Anyway, still plugging away here. I should be making some progress this week.

[SteveA]

As you may be aware, I'm making modifications to Bxbasm so that it assembles with both Jwasm and Masm, seamlessly.
I am a bit concerned about continuing with Jwasm, tho'.

Nearly a month ago, Japheth posted this message on SourceForge:

2011-12-15 00:36:41 PST

Hello,

I'm busy with real life issues and cannot work for JWasm currently.

I hope that this state will change in 01/2012.

japheth

http://sourceforge.net/projects/jwasm/forums/forum/927109/topic/4883161

Hmmm,
The last time I said something like that was back in 2004, when I suspended development on Bxbasm..., until now.
Again, mine was due to real life issues as well.

[jcfuller]

Steve,
  JWasm is quite stable so what are your concerns?

Maybe take another approach with LLVM?

http://llvm.org/

James

[SteveA]

  JWasm is quite stable so what are your concerns?

I agree, it does seem quite stable.
My only concern is that I don't know what JWasm lacks.
If there are unknown, undocumented features or bugs that japheth hasn't the time or desire to fix.
I didn't start using Jwasm when it first came out for those same reasons.

That is one reason why I have used Masm for so many years.
Despite the fact that MS has discontinued support for Masm, they still supply new versions with their software packages.

We've all seen so many projects abandoned in mid-stream, just when they were getting good.
I'm happy to be using JWasm. It seems to be doing everything I need it to do, at the moment.
But, then, I've only started.

I'm not going to stress over it too much.
I've got a lot of work to do on Bxbasm that will keep me occupied for a fair amount of time.
Hopefully japheth will be able to find some spare time to keep jwasm updated.

[SteveA]

I'm still here, plugging away, every day or every chance I get on Bxbasm.
I'd like to put out a new release, but, I keep finding issues I need to deal with.
I hate putting out something that I know will be seen as being buggy.

I'm still working on writing a replacement for the Masm32 utilities, macros and routines.
Right now I'm trying to create a solution to comparing real numbers with the FPU and being able to branch in the right direction.
In case you didn't know it before, the x86 has a great set of compare and branch instructions.
Unfortunately, these are only x86 instructions and only work with integer values.
There are no FPU compare and branch instructions for testing real numbers and branching based on the test result.
This seems really odd to me, that the designers didn't feel the need.
The solution, (if it truely is a solution, as it's more of a work-around), is to use a combination of both instruction sets.
This is not an ideal solution.

[John]

I hate putting out something that I know will be seen as being buggy.

We can't help or learn if we can't see code.

This is what AllBasic is about, developers helping developers.

I'm looking for help building a cross platform IDE using IUP for ScriptBasic. I would like to use the GUI layout tool that comes with IUP for the GUI designer and incorporate the ScriptBasic sdbg debugging pre-processor into the mix for single step execution and variable display.

I'm currently working on finishing up the CD (canvas draw) extension to the IUP API. Building an IDE would also shake out any issues that might still be hiding.

[SteveA]

We can't help or learn if we can't see code.

This is what AllBasic is about, developers helping developers.

You're right.
I'll see if I can put something together today and upload what I have, (bugs and all).
Uploading raw code is not a problem, by something I mean documentation, because the current docs don't account for all the changes made.
I kind of need to explain what works and what's different.

[Charles Pegge]

Steve,

For FPU comparisons use FCOMI / FCOMIP. This directly sets flags in the CPU. (but not the sign flag). So you can branch with JA JB JAE JBE JZ JNZ.

FCOMI / FCOMIP only works between st(0) and st(1..7). And the comparison is in reverse to what you would normally expect. So try with a few simple cases to get the right polarity.

Charles

[jcfuller]

I see by the source this is to be Windows Only?
I thought one of the reasons for using JWasm was the possibility of a Linux version??
And LccWin32?

James
 

[jcfuller]

I did manage to compile with gcc by commenting out :
//#define LccWin32
and
//#include <winuser.h>.
so linux port may be possible after all?
Have not tried running it yet.

James

[SteveA]

For FPU comparisons use FCOMI / FCOMIP. This directly sets flags in the CPU. (but not the sign flag). So you can branch with JA JB JAE JBE JZ JNZ.

Thanks for the information Charles.
I did manage to locate some of that on another forum, but, your reply was the most direct and to the point.

Thanks for the information Charles.
And the comparison is in reverse to what you would normally expect. So try with a few simple cases to get the right polarity.

Yes, I did discover the polarity issue.
At first I wondered what was going on.
So I played with it until I understood what was happening.
Thanks

[SteveA]

I see by the source this is to be Windows Only?
I thought one of the reasons for using JWasm was the possibility of a Linux version??

You are correct about Linux.
I figured that a Linux version can simply omit the windows specific stuff.

Note, this is not, in any way, an official release.
This is just an opportunity for you to see the work-in-progress as it is, at this point.
This is not something I would ever release for general consumption.
I figure, since this is a developer site, it's fair to share what's under the hood (so to speak).

Right now, I'm just trying to get what I had previously written, re-written and headed in the right direction and stable.
Bare in mind, that's the major reason why I have not up loaded anything until now.
There was just too much revising taking place.

Only now, is most everything working again.
At one point, most everything was broken and not in a working state.

And LccWin32?

I prefer LccWin32.
Over the years that I have been using it, I have found Lcc to be extremely stable and reliable.
Plus, if I have a problem or a question about something concerning Lcc, I can email Jacob Navia and we discuss it.
It's nice to have a one-on-one with the developer.