Hi everyone!
Thank you very much for all your interesting comments on Oxygen Basic. I was about to announce the project on this forum, but John got in there first :)
I am more than satisfied with FreeBasic as a development language. While I have not made use of its more advanced features, it has proved to be very reliable, and interfaces nicely with assembly code. Thank you Joshy for posting the compatibility fix with FB 0.21
O2 was conceived nearly three years ago as a machine script, in essence machine code with a linker. It was an experiment to see how minimal a compilable language could be. Then came the Assembler shortly followed by a macro language. Eros Olmi (of thinBasic) suggested more people would be able to understand it if I added Basic-like syntax. So I thought okay, I'll have this ready in a few weeks. Little did I know how much work was involved in producing a high level compilable language. A compiler has to spend much of its time doing invisible things like automatic type conversion and operator precedence and one is not fully aware of these complexities until you try to encode them.
Even before adding Basic, I had OOP capability in place. I think retrofitting it to a straight procedural language would have been much more difficult which I think is why many Basics have got stuck in their development.
One very importand and most recent feature in the development of o2 is the ability to read C headers as well as Qbasic headers. This requires O2 to understand quite a large chunk of C itself. So far, this fusion of C and basic has not been too problematic. A Few directives are needed. For instance partial case sensitivity: #case capital which distinguishes fully capitalised keywords.
I use the term JIT because O2 compiles directly to an executable memory image which may be used immediately without first storing it to an EXE file. For programs up to about 40-50k of source code, the compilation time is barely noticeable. This is good for ad-hoc programming where you are not building a static application. The source code is the only item that needs to be stored.
Currently O2 compiled executables depend on Oxygen.dll for the run-time library, but I am working on the 'independent' mode where the run-time library is included. This is of course essential when generating 64bit code with a 32 bit compiler.
I am still devoted to GOTOs. But I have only used them very sparingly 372 times :D. Many of these are error trapping points, and many GOTOs are directed towards a small number of nodes in the program.
It will take about three more months to approach Beta quality releases. Much of the testing at this stage involves exposing Oxygen to as many different situations as possible and testing with various APIs.
Charles
http://oxygenbasic.sourceforge.net
However porting to SB, being a scripting language would pose a few problems like being unable to tightly couple Assembly code with the host script.
$ASM directive
Purpose: The $ASM directive allows inline assembly instructions to be used with BCX. An $ASM directive must be placed before and after the assembly statements.
Syntax:
$ASM
/** Assembly statements go here */
$ASM
GOSUB ... RETURN statement
Purpose: GOSUB redirects program flow to a label. The flow continues from the label until a RETURN statement is encountered and the flow is returned to the line following the GOSUB Label statement.
Syntax:
GOSUB Label
Label:
Statements
RETURN
DIM j
CLS
PRINT "Calling Subroutine 9 times ..." : PRINT
FOR j = 1 TO 9
GOSUB qwerty
NEXT j
PRINT : PRINT "All Done!"
END ' Don't accidently fall into the subroutine
QwErTy: ' BCX Subroutine Labels are NOT case sensitive
PRINT " This is instance >>", j, " << of the subroutine call."
RETURN ' Return from subroutine back to main program
Oxygen makes intensive use of FreeBasic Inline Assembler (which is slightly preprocessed GNU GAS using Intel notation). The Oxygen Assembly language is largely compatible with this. We also have a high degree of compatibility between FreeBasic and OxygenBasic language.
fbc -gen oxygen hello.bas
The GNU Assembler (GAS) is the default back-end to the GNU Compiler Collection (GCC) suite. As such, GAS is as portable and retargetable as GCC is. However, GAS uses the AT&T syntax for its instructions, which some users find to be less readable than Intel syntax. As a result, assembly code written inline in a C code file for GCC must also be written in GAS syntax.
GAS is developed specifically to be used as the GCC backend. GCC always feeds GAS syntactically-correct code, so GAS often has minimal error checking.
GAS is available as a part of either the GCC package or the GNU binutils package.
The important thing at present is to work with a single "incarnation" of Oxygen when making a large number of changes.
But I have not ruled out Oxygen self-compilation if C presents too many obstacles ...
QuoteBut I have not ruled out Oxygen self-compilation if C presents too many obstacles ...
Nothing ugly about BCX ASM inclusion.
The help file I believe shows asm if code is compiled with Pelles.
I added a Poll to the thread asking the question ... (see top of page to vote)
What is your language preference to build OxygenBasic?
I actually don't see the hurry to leave FreeBasic at all. It served Charles well and it can do so for years to come.
efgee