OpenEuphoria

Euphoria To C Translator Optimisations (2)

• Posted by Mike The Spike <mtsreborn at yahoo.com> Feb 01, 2001
• 458 views

Here's a new list of ways on how to optimise E2C;

- Output 'register' instead of 'int' for integers
embedded inside a heavy loop. (Easy to implement,
requires an optimisation pass on the C code)
- Change sequence initialisation code from this;
 *((int *)(_2+0)) = 9;
 *((int *)(_2+4)) = 34;
 *((int *)(_2+8)) = 14;
 *((int *)(_2+12)) = 18;
 *((int *)(_2+16)) = 33;
 *((int *)(_2+20)) = 46;
to this:
*((int *)_2 = *((int *){9,34,14,18,33,46};

Not only is it faster in some cases (for the C
compiler might output better array assignment code),
but it's smaller and more elegant, plus easy to read
an understand.
(This is easy to implement, yet hasn't being tested by
me yet.)

- DEFINTELY make de_reference() and NewS1() 'inline'
functions. ie. they are declared as for ex. 'inline
int myfunc()'. This saves calling overhead an speeds
up all applications globaly by a large percentage.
*everything* will run faster because of this.
(This is extremely easy to implement! Some compilers
support '_inline' instead of 'inline', but that's easy
to lookup)

- It's RECOMMENDED that binary_op_a() and NewDouble()
are inlined aswell.

- The following code from EC.exe for DJGPP:
((unsigned)poke4_addr > (unsigned)0x000FFFFF)
            *poke4_addr = (unsigned
long)DBL_PTR(_dest)->dbl;
        else

(unsigned long)poke4_addr, (unsigned
long)DBL_PTR(_dest)->dbl);

Should be eliminated.
Why?
Because A. The check perfomed slows things down.
B. It's not portable. _farpoke[l]() is a Go32 specifc
function.
This would hae as result that you can't compile your
Euphoria programs by using, for example, a user
contributed ec_psx.lib runtime library for the
playstation using EC.EXE.

I expect that if rob does release the source to the
runtime library, it will be the one for Win32, and
will have code like the following to let you compile
your code with non-windows C compilers:

#ifdef WIN32
void _stdcall WinMain( ... )
{
   ...
}
#else
void main( ... )
{
   ...
}
#endif

Remember that only ONE of the above two main entry
points is compiled, if 'WIN32' is defined by the
compiler, ie. you're using LCCWin or whatever,
WinMain() will be compiled and main() will not be
compiled, it will totally be ignored by the compiler.
Therefore there are no executable size reasons why not
to implement this.
But I guess you allready knew that :P


So to conclude things,
the easiest and cheapest way to gain some overal,
evaluation, and arithmetic speed increases is by
defining much-called runtime routines as inline.


Mike The Spike
PS. Yes these are straight-forward and simple
optimisations, but that's about the best I can do
right now. The best thing to do to get more speed is
optimise the way Euphoria is mapped to C. But this is
hard for me to do right now.