1. variables
- Posted by Tuxedo Mask <nitrogen at XTRA.CO.NZ> Oct 25, 1997
- 659 views
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
- Posted by Robert Craig <rds at CLASSIC.MSN.COM> Oct 25, 1997
- 670 views
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
- Posted by Daniel Berstein <danielberstein at USA.NET> Oct 26, 1997
- 646 views
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