OpenEuphoria

Re: graphics.e

• Posted by Robert Craig <rds at EMAIL.MSN.COM> Jul 25, 1998
• 630 views

Robert McDougal writes:
> Curious about GRAPHICS.E.  It calls MACHINE_PROC or
> something like that for everything.  Since the underlying code
> for these functions is already embedded in the Euphoria
> interpreter, wouldn't it be more efficient to just have it
> directly support the various graphics statements.

That's a good point.
The reason it's done this way is to reduce the number
of names that are reserved by the language, i.e.
names that you can never use for your own routines,
variables etc. It also avoids making the symbol table larger.
At the moment, there aren't a huge number of global symbols
contained in all the standard .e files, but the number will keep
growing as new routines are added.

Routines are likely to be built-in to ex.exe (exw.exe),
and given a reserved name when:
      * they are needed in many programs
      * they are called a lot
      * the overhead of calling the routine via machine_proc/func
        would be significant compared to the time spent
        inside the actual routine

Prior to 1.5a, pixel, get_pixel, mem_set, and mem_copy
were implemented via machine_proc/func calls. In 1.5a
they were made official built-in routines with reserved
names. This cut the overhead on calling these routines
and made game developers and others happier.

BTW, in the past few days I managed to slash the overhead
involved in calling plus returning from a Euphoria routine.
Normal calls, call_proc/func calls via a routine id,
and call-backs (WIN32) now have "1/3 less fat". Only
recursive calls stay the same. For many programs
this makes a big difference. One of Kernighan's
benchmarks (sum) is running 40% faster, mostly
due to this call optimization.

Regards,
     Rob Craig
     Rapid Deployment Software
     http://members.aol.com/FilesEu/