Would it be possible to convert XBLite compiler to use LLVM compiler backend suite? Or it would be such a big rewrite that it's impossible?

Well it appears that LLVM uses a GCC(C/C+) frontend, so I don't see how it could possibly work as Xblite emits GoASM code.  Which I doubt the LLVM people would ever support GoASM as it is Windows only(well besides the object converter for linux), and LLVM uses GCC not mingw/cygwin.  The core problem is that LLVM compiles only C/C++ code, so there is no way it would work.

I have looked at such ideas several times in the past, including in the recent past.  I have specifically considered LLVM, but I don't see it working for xblite, it would be a radical change.

The compiler is very complex.  My only xblite project to date has been improving the compiler system, and I would say that I understand less than 50% of how the compiler works.  I imagine David would say much the same thing.

Greg

Quoted from Rhett Thompson

Well it appears that LLVM uses a GCC(C/C+) frontend ...

Yes, but I was reading in some papers it's actually bytecode machine (there was said kinda like java) capable of static compiling and that frontends are switchable, but maybe I got it wrong. So theoretically same byte code emitter for XBLite could be written.

Quoted from 13

I have looked at such ideas several times in the past, including in the recent past...

It's a pity such a great language is locked on Windows and x86 architecture. Thanks for replies anyway.

Quoted Text

Yes, but I was reading in some papers it's actually bytecode machine (there was said kinda like java) capable of static compiling and that frontends are switchable, but maybe I got it wrong. So theoretically same byte code emitter for XBLite could be written.

Ahh...I would bet it would be easier to just write a new Xblite->LLVM opcodes, instead of trying to modify the Xblite compiler in some way.

Quoted Text

It's a pity such a great language is locked on Windows and x86 architecture. Thanks for replies anyway.

I agree it kinda sucks that Xblite is constrained to Windows, however I think it would be possible if GoASM supported Linux or another OS.  Then it would be just a matter of Xblite emitting the correct entry procedures(and stuff) right? I read in the GoASM manual you can convert its outputted object files to Linux format, which then could be built to run on Linux...no idea if it works though.

Later.

Quoted from Rhett Thompson

Ahh...I would bet it would be easier to just write a new Xblite->LLVM opcodes, instead of trying to modify the Xblite compiler in some way.

Interesting idea, yet I was once reading through code, and maybe it wouldn't be so hard to modify the current emitter. However I got quickly lost as Max Reason, highly intelligent person, that he is, used plenty of control goto tables and other esoteric stuff which is not that easy to grasp.

Quoted from Rhett Thompson

I agree it kinda sucks that Xblite is constrained to Windows, however I think it would be possible if GoASM supported Linux or another OS.  Then it would be just a matter of Xblite emitting the correct entry procedures(and stuff) right? I read in the GoASM manual you can convert its outputted object files to Linux format, which then could be built to run on Linux...no idea if it works though.

Another interesting idea maybe worth a try. Then there is always the WINE. But anyway, even when this works, it won't break the x86 barrier. Not that I have access to other arch, but some people might be missing such thing.

Quoted Text

Interesting idea, yet I was once reading through code, and maybe it wouldn't be so hard to modify the current emitter. However I got quickly lost as Max Reason, highly intelligent person, that he is, used plenty of control goto tables and other esoteric stuff which is not that easy to grasp.

My point exactly.  I'd say the compiler is far too evolved and complex to just change a core thing like the emitter.  And besides writing a new language translator would give the person the ability to address some of the problems/constraints to the current compiler.

Quoted Text

Another interesting idea maybe worth a try. Then there is always the WI ...

I experimented with it last night(between my Mass Effect addiction), and I was able to get that simple GoASM program to run on Ubuntu 8.02.  However, Xblite emits way too many Windows dependencies, and unsupported labels right now.  Still I think adding some kind of option to the compiler to emit Linux compatible GoASM code, would be far easier than writing a new compiler for portability.  You only need two tools from MinGW(ld.exe the linker, and objcopy.exe to convert COFF objects files to elf32), which could be added to the Xblite distribution.  So unless modifying the emitter to do this is incredibly difficult I think that would be the best solution.

The easiest (but remaining quite difficult) solution to what we are discussing here is to port xblite to FASM.  If anyone wants to do that, xblite is GPL and LGPL open source, and nobody would have any reason to object, if it is done in accordance with the license.  I ported to GoAsm, someone else can do FASM  ;)

I chose GoAsm for three reasons -
1) I understood it.
2) It worked.
3) Jeremy, the author of GoAsm, was very supportive in fixing any GoAsm issues I found that impeded the process.

That is the easy first step.  But there remains the problem of the libraries, which are dependent on the Windows API.  They would have to be rewritten to work under Linux.  This would require low-level (assembly) programmers who understand the Linux API.  It would require new "core" developers, as I doubt anyone currently supporting the Windows side would be able to concurrently do the same for the Linux side.

Concerning the complexity of the compiler, I agree that it is very complex.  I have thought about a total rewrite, and each time I think about it I realize that is a project that would never be completed to the stage where xblite is now.  It would be a huge step backwards, that would take development time away from productive improvements in the compiler system.  There is no assurance that the end product would be better or more understandable than what we have now.  For that reason, I believe the way forward is to continue to improve and build on the code base we already have.

That is my point of view, today, subject to change anytime.

Greg

Quoted from Rhett Thompson

I agree it kinda sucks that Xblite is constrained to Windows, however I think it would be possible if GoASM supported Linux or another OS.  Then it would be just a matter of Xblite emitting the correct entry procedures(and stuff) right? I read in the GoASM manual you can convert its outputted object files to Linux format, which then could be built to run on Linux...no idea if it works though.

Later.

XBLite is just a fork from the XBasic source. If you truly want to work on a LINUX version, then
start with XBasic for Linux. All the source is available. Max's idea of being able to run exactly the
same XBasic code under both LINUX and Windows was brilliant but ultimately not supportable.
In the long term it would require a several programmers to deal with every OS change and
variation.

Plus, a new updated and streamlined version for LINUX would unable the use of
native GUI's available for LINUX.

ciao,
D.

Quoted Text

The easiest (but remaining quite difficult) solution to what we are discussing here is to port xblite to FASM.  If anyone wants to do that, xblite is GPL and LGPL open source, and nobody would have any reason to object, if it is done in accordance with the license.  I ported to GoAsm, someone else can do FASM

Too hard.

Quoted Text

But there remains the problem of the libraries, which are dependent on the Windows API.  They would have to be rewritten to work under Linux.  This would require low-level (assembly) programmers who understand the Linux API.  It would require new "core" developers, as I doubt anyone currently supporting the Windows side would be able to concurrent ...

Well you wouldn't absolutely have to use the Xblite libraries, you could just use the C libraries.

Quoted Text

XBLite is just a fork from the XBasic source. If you truly want to work on a LINUX version, then
start with XBasic for Linux. All the source is available. Max's idea of being able to run exactly the
same XBasic code under both LINUX and Windows was brilliant but ultimately not supportable.
In the long term it would require a several programmers to deal with every OS change and
variation.

I'm not bent on Xblite for Linux or anything, just happy thoughts:)  And I don't think the changes are as drastic anymore, except between distros maybe...which therein lies the problem I think.

Quoted Text

Plus, a new updated and streamlined version for LINUX would unable the use of
native GUI's available for LI ...

Not really sure what you mean there.  Anyways you would kinda be screwed, unless you were developing for Gnome(GTK). Because KDE uses Qt which is heavy OOP.

Anyhow, I think the next evolution should be Xblite Script, witch some OOP capabilities:)

Yeah I realized XBLite is trimmed down XBasic. However were some new XBlite features back-ported to XBasic ? Like the newer integer types etc.