I see the names are thoroughly decorated.
The main tendency seems to be to auto-capitalize BASIC names so that they don't shadow or overload the associated C functions and macros inadvertently.
In a high-level emitter, one would try to keep the names close to the original source, and most of the code, except for string stuff, could be translated like a C-BASIC macro.
I don't care very much for the quality of
their C emission. And clearly enough, their set of string stuff embedded in their custom gcc 4.7.1 and/or cc1 will have to be substituted for a set of equivalent O2 helpers in a separate module/library included in the O2's Code::Blocks project. But the main part of O2 can be converted at once, hehe, and only once if you pardon me this pun, and used henceforth for manual optimization/improvement/development without resorting to FB and/or its gcc emitter ever after.
Of course, BCX translations look much more elegant than this one but BCX would also require that O2 sources be translated to, or rewritten in, BCX first which would add some extra headache to the whole task.
OTOH the Toy interpreter experiment shows that the gcc emitter works in principle and it can generate (some) usable code directly from FB sources, and O2 is currently written in FB.
The run-time in Oxygen, which contains all the core functions, is about 12k of tightly coded binary, mostly from assembly code. This would have to be translated into C, without using Assembler, to include with every program.
That's correct. But that's an inevitable price of extending O2 to non-Intel platforms (see also below) and relying on the quality of corresponding gcc machine code emitters
and optimizers for the other CPU architectures supported by gcc.
Inevitably, the end result will not be as efficient or compact.
That's correct too. But very low-level and carefully handcoded integer and pointer based C source is usually compiled by gcc to very clean and predictable assembly on at least i386. I understand that your existing i386 assembler is also very valuable, probably as much as Oxygen as a whole. But it will stay valid not only for Windows but also for desktop Linux and Mac OS X that are all currently running on Intel CPU's. The asm sources for these platforms may stay as they are, featuring C wrappers for decoration purposes only.
Again, there are a lot of optimizations that gcc can offer out of the box. Each module of the project can have its own optimization level and some modules less sensitive to speed can also be optimized for smaller size. Believe me, this sort of optimization is also very efficient.
Furthermore, I think the current (quite unreasonable) size of toy2.exe is due to its int functions not having been explicitly declared as integers, which enforced gcc to compile unnecessarily its floating-point paraphernalia into the executable.
And finally, I think such a strategy could compensate at least partially for my miserable failure to fulfill my obligations earlier this year when I let you down due to my illness and subsequent political developments in the neighboring country that happens to be my motherland.
