1. variables
TO ROBERT CRAIG:
do you think you could add to euphoria a function that would return the
memory address at which a variable is stored? this may help making some
of our machine code a bit faster since poking the data that the
procedures need would not be nesecary on _every_ call.
--Mark Honnor;
--------------
2. Re: variables
Mark Honnor asks:
> do you think you could add to euphoria a function that would return the
> memory address at which a variable is stored? this may help making some
> of our machine code a bit faster since poking the data that the
> procedures need would not be nesecary on _every_ call.
I doubt that I will ever give you the address of a variable.
It's a bad idea for many reasons. It could really foul
up the garbage collection mechanism if you could
change the value of a variable via direct access to memory.
It would also force me to document the exact format of
atoms and sequences. I've changed this format several
times over the years, and I would not want to have to freeze it
to avoid breaking your code. For instance, 1.5a uses a slightly
different format for sequences than 1.5. On top of that,
the address where a variable's data is stored is not fixed.
It can (and often does) change during execution.
I think it's a healthy situation that Euphoria programs cannot
know the internal format, and can't read or modify variables in dirty
ways using pointers. It also makes it easier to do certain optimizations when
Euphoria can see from the source code exactly the places where a
variable's value might be used or modified. If you use a memory address,
the optimizer wouldn't always know which variable you are trying to use.
Regards,
Rob Craig
Rapid Deployment Software
3. Re: variables
On 25 Oct 97 , Robert Craig wrote:
> I doubt that I will ever give you the address of a variable.
> It's a bad idea for many reasons. It could really foul
> up the garbage collection mechanism if you could
> change the value of a variable via direct access to memory.
> It would also force me to document the exact format of
> atoms and sequences. I've changed this format several
> times over the years, and I would not want to have to freeze it to
> avoid breaking your code. For instance, 1.5a uses a slightly
> different format for sequences than 1.5. On top of that, the address
> where a variable's data is stored is not fixed. It can (and often
> does) change during execution.
>
> I think it's a healthy situation that Euphoria programs cannot
> know the internal format, and can't read or modify variables in
> dirty ways using pointers. It also makes it easier to do certain
> optimizations when Euphoria can see from the source code exactly the
> places where a variable's value might be used or modified. If you
> use a memory address, the optimizer wouldn't always know which
> variable you are trying to use.
I think the point here is to be able to have in-line assembly. Maybe
in a future version you can support basic inline assembly and just
let Euphoria handle variable references. Example:
integer num
sequence seq
seq = {1,2,3,4}
num = 2
asm
mov ax, seq[num]
.
(etc)
.
end asm
The Euphoria interpreter should make the translation to machine code
assigning the current memory address of the refered variable(s) on
runtime.
Regards,
Daniel Berstein
danielberstein at usa.net
http://www27.pair.com/daber/architek
