1. whaddabout a VARPTR func?
Hello all.
It occured to me some time ago that a new function for DOS/Win? Euphoria
that returns pointers to variables in memory like BASIC's VARPTR() would
allow for some serious performance improvements when using embedded
assembler or virtual screens in programs. It would also make new things
possible like super high speed math functions or the like.
Of course one would need to take into account and translate Euphoria's
internal number format if necessary. One may also need to restrict
one's choice of sequence structure, and maintain it during any external
alterations. Externally inserting or deleting objects would not be
expected. All this could be dealt with by the programmer.
What do you think? Surely someone could second me on this, that I not
be shot down in flames on my own :)
--
Nick Metcalfe <metcalfn at alphalink.com.au>
http://www.alphalink.com.au/~metcalfn
2. Re: whaddabout a VARPTR func?
Nick Metcalfe writes:
> It occured to me some time ago that a new function
> for DOS/Win? Euphoria that returns pointers to variables in
> memory like BASIC's VARPTR() would allow for some
> serious performance improvements when using
> embedded assembler or virtual screens in programs.
This has been suggested before from time to time.
On the surface it may sound like a good idea. However
it will probably never be implemented because:
- It would force me to freeze the current internal format for data.
This format has changed many times, leading to enhanced
performance, and change was only possible because no
program depends on the format.
- It would open a "Pandora's Box" of evil code that would
access and alter variables in ugly and invisible ways.
You'd see a lot of unexplained crashes and weird behavior,
that would tend to be blamed on Euphoria itself.
- It would reveal proprietary information that might
help the competition to make faster interpreters
(Rebol 44x slower?, Perl 34x slower? Python 34x slower?)
- A variable's value is not always stored at the same place.
A fixed varptr address is not that meaningful in the context of
garbage collection etc.
- You wouldn't get the full speed-up that you imagine.
The machine code would have some of the same
overheads as the interpreter when reading the
internal format.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
