1. graphics.e
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. Wouldn't the extra time processing
strings instead of a number be made up for by not having to search through the
procedure list or whatever? Or is that a portability thing? A different
GRAPHICS.E might be designed that would be used in a Euphoria compiler if someone
can figure out how to do that efficiently? Is there supposed to be a sound
function in there too? These things just seem a bit strange to me, that's all.
Just thinking,
- Robert McDougal
PS: I tried to write a routine that directly did the graphic stuff (in assembly
language) about a month ago, and it bothers me greatly because (except for mode
19), I can't get the graphics to work right without using the BIOS routines for a
pixel. They take WAY too long to do anything on my system. (Probably too long
on any system.) When I come across something that I can't get to work, it bugs
me forever until I can do it. So can someone PLEASE PLEASE either try and
explain it to me (maybe you'll have better luck getting it through my skull), or
point me to some working asm code that sets a pixel, draws lines, whatever.
(Most important, pixel setting.) Thank you so much.
Free web-based email, Forever, From anywhere!
http://www.mailexcite.com
2. Re: graphics.e
Robert McDougal wrote
>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. Wouldn't the extra time processing strings instead of a
>number be made up for by not having to search through the procedure
>list or whatever?
You must have an old version of graphics.e, the new one certainly does not
call MACHINE_PROC for everything.
Einar Mogen
3. Re: graphics.e
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/
