New Basic Compiler
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
New Basic Compiler
Charles Pegge released a standalone version of his JIT Basic compiler. (Oxygen Basic) I think he has something (even in it's alpha form) worth having a peek at.
http://www.allbasic.info/forum/index.php?topic=8.0
http://www.allbasic.info/forum/index.php?topic=8.0
That post is a bit strange. It compiles straight to x86, and accesses C directly, but is a JIT ?
duke4e: I don't see anything about an interpreter in the post? He describes it as a JIT compiler.
But it sounds like a native, standalone backend AND has Inheritance. It is the first time John posted a new tool that actually holds some attractions.
Bad name though, Oxygene is already taken as name for a JIT development tool (though it is also marketed as "Delphi Prism" http://www.remobjects.com/oxygene.aspx)
John: a post how sources are split up in multiple modules would also be nice.
duke4e: I don't see anything about an interpreter in the post? He describes it as a JIT compiler.
But it sounds like a native, standalone backend AND has Inheritance. It is the first time John posted a new tool that actually holds some attractions.
Bad name though, Oxygene is already taken as name for a JIT development tool (though it is also marketed as "Delphi Prism" http://www.remobjects.com/oxygene.aspx)
John: a post how sources are split up in multiple modules would also be nice.
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
This one is Oxygen and not Oxygene as mentioned above...
AFAICS Oxygen is both:
1.) JIT compiler - compiles source code fast and executes it in memory
2.) Native compiler - compiles source code to executable files (assembler, linker)
I've tested Oxygen and must say it compiles very, very fast - at least for the short examples that are provided.
The only "downside " (if you can call it that) is that a resulting executable is small but depends on a runtime dll (Oxygen.dll).
And it looks like this runtime dll is actually the compiler itself.
Unusual approach but... it's one way of doing it.
I suppose if the runtime portion of the compiler dll could be compiled in a separate dll the runtime dll could be far smaller.
Or better convert the runtime in OxygenBasic and link it into the compiled exe...
Also the footprint of Oxygen is incredibly small.
All in all IMHO it's a neat project that deserves attention, especially when it's coded in FreeBASIC (source code of the ThinBasic version is available in the ThinBasic Forum - don't know if Charles makes the code of the standalone version available).
IMO this project shows how mature FreeBasic actually is!
This said, both projects (FreeBasic and Oxygen) deserve my respect.
fsw
AFAICS Oxygen is both:
1.) JIT compiler - compiles source code fast and executes it in memory
2.) Native compiler - compiles source code to executable files (assembler, linker)
I've tested Oxygen and must say it compiles very, very fast - at least for the short examples that are provided.
The only "downside " (if you can call it that) is that a resulting executable is small but depends on a runtime dll (Oxygen.dll).
And it looks like this runtime dll is actually the compiler itself.
Unusual approach but... it's one way of doing it.
I suppose if the runtime portion of the compiler dll could be compiled in a separate dll the runtime dll could be far smaller.
Or better convert the runtime in OxygenBasic and link it into the compiled exe...
Also the footprint of Oxygen is incredibly small.
All in all IMHO it's a neat project that deserves attention, especially when it's coded in FreeBASIC (source code of the ThinBasic version is available in the ThinBasic Forum - don't know if Charles makes the code of the standalone version available).
IMO this project shows how mature FreeBasic actually is!
This said, both projects (FreeBasic and Oxygen) deserve my respect.
fsw
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
I use Kaspersky Internet Security and it doesn't have a problem with it. I remember a while back on the thinBASIC forum they were having issues generating a standalone executable without antivirus apps complaining. (which was a packed set of files including the interpreter)
Charles is a smart and generous person and I trust whatever he offers as a download.
Charles is a smart and generous person and I trust whatever he offers as a download.
-
- Posts: 453
- Joined: Dec 24, 2005 2:32
- Location: WA - USA
- Contact:
Charles and I got the Oxygen Basic JIT compiler embedded in ScriptBasic if you want to take a peek at that aspect of the compiler.
http://www.allbasic.info/forum/index.php?topic=13.0
http://www.allbasic.info/forum/index.php?topic=13.0
@John
I just read your blog (daughter) and uhm... anyway, back to programming (no need to get all emotional here).
I think the idea of having an interpreter (JIT or not) is not such a bad idea. The main advantage of having an interpreter is (usually) ease of debugging. Most interpreters have some facility you can hook into to get a debugging facility going (LUA has it's hooks, Python has it's facilities(pdb, peval etc....)).
Combining the benefits of an interpreter (debugging) with the benefits of native code runtime performance (by turning the bytecode into executable code using Ahead of Time compilation) sounds like a good idea to me.
Microsoft does something like that with the .NET framework (it can turn CIL into native code), GCJ can turn Java bytecode into native code and there are more projects out there doing the same thing.
Oxygen is closely related to ThinBasic which has a nice debugging facility (ThinBASIC is a BASIC interpreter).
ThinBASIC and Oxygen are not open source though.
Scriptbasic is open source.
I just read your blog (daughter) and uhm... anyway, back to programming (no need to get all emotional here).
I think the idea of having an interpreter (JIT or not) is not such a bad idea. The main advantage of having an interpreter is (usually) ease of debugging. Most interpreters have some facility you can hook into to get a debugging facility going (LUA has it's hooks, Python has it's facilities(pdb, peval etc....)).
Combining the benefits of an interpreter (debugging) with the benefits of native code runtime performance (by turning the bytecode into executable code using Ahead of Time compilation) sounds like a good idea to me.
Microsoft does something like that with the .NET framework (it can turn CIL into native code), GCJ can turn Java bytecode into native code and there are more projects out there doing the same thing.
Oxygen is closely related to ThinBasic which has a nice debugging facility (ThinBASIC is a BASIC interpreter).
ThinBASIC and Oxygen are not open source though.
Scriptbasic is open source.
This largely doesn't make sense. The interpreter is on the level of the bytecode (which is stylized assembler), not on the level of the target language.AGS wrote:@John
I just read your blog (daughter) and uhm... anyway, back to programming (no need to get all emotional here).
I think the idea of having an interpreter (JIT or not) is not such a bad idea. The main advantage of having an interpreter is (usually) ease of debugging. Most interpreters have some facility you can hook into to get a debugging facility going (LUA has it's hooks, Python has it's facilities(pdb, peval etc....)).
Combining the benefits of an interpreter (debugging) with the benefits of native code runtime performance (by turning the bytecode into executable code using Ahead of Time compilation) sounds like a good idea to me.
I said largely, because most JIT languages are a bit more self describing, and the debugger could somehow plugin into that a bit.
But that is secondary damage control (essentially a slightly different way of debug info loading)
They are JIT yes, but their debugger parts are just hard work (very hard even, since fullblown JITs are more complicated than native compilers), not a logical consequence of them being JIT.Microsoft does something like that with the .NET framework (it can turn CIL into native code), GCJ can turn Java bytecode into native code and there are more projects out there doing the same thing.