1. Euphoria compiler?
Hi Robert!
I was woundering just how hard it would be to
translate to ASM instead of C.
To be compiled/linked by NASM, wich can link to DOS32,
Win32 and Linux image files.
Allthough it would be a real unportable sollution, it
might gain you some speed here and there.
I'm saying this because the C code produced bythe
translator maps very well to ASM code.
With the gotos, and the runtime library.
The runtime library is the real reason why I'm
proposing this.
Because it allready handles all of Euphoria's
internals
in C. All you should do is call the routines in the
runtime library from an ASM file.
I looked into it and it's very easy.
Especially in NASM where you have macros that can
handle anything.
For example, you can use 'if/while/else' in your ASM
code.
All that would be different from the Eu To C
translator would be the syntax.
ASM is truly overrated when it comes to complexity.
Generating machine code is a real pain, I admit, but
generating ASM is not.
The basic layout of a C program translated from
Euphoria would remain intact, as it maps very well to
ASM.
In NASM you can define structures, arrays, etc.
So the datatypes declared in the C sources can be
mapped to ASM.
Personally, I wouldn't do this project though.
But that's because my main focus is portability, and
it always will be.
Yours might be Intel-based OSs, so you might consider
doing this eventhough it's not portable.
Myself, I would rather output code like the following
from the translator to accieve the same speed gains
(if any) in C portably without translating to ASM
entirely;
#ifdef MSVC
__asm push eax, &var1;
__asm add eax, &var2;
#else
var1+=var2;
#endif
But you might still want to do an Eu To ASM translator
because of the shear ease of doing it thanks to the
way the translator currently outputs C code.
But then again, maybe Beta-1's speed gains over
Alpha-3
are large enough to not even touch ASM ;)
Mike The Spike
PS. I still think declaring atoms as floats would be a
good optimisation to implement. :)
