1. address of variable
Rob:
Why is it so difficult for Euphoria to return the address of a
variable ?
Since we can not pass a variable by reference; this would give
the programmer a way to access a variable inside a procedure
or function.
It would not have to be any more than a simple function that
returned a memory address of a given variable.
If the variable is not available then it would return -1
If swapping out of memory is a problem then you could have the
programmer declare them as special locked variables.
Bernie
2. Re: address of variable
- Posted by Robert Craig <rds at ATTCANADA.NET>
Dec 15, 1999
-
Last edited Dec 16, 1999
Bernie Ryan writes:
> Why is it so difficult for Euphoria to return the
> address of a variable ?
It isn't difficult. It's just a really bad idea
for many other reasons. Here's my post on this
subject from a few weeks ago...
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
3. Re: address of variable
Rob:
I think that a programmer should be able to store data in a
global variable inside a procedure or function. ( I don't need to
know the variables address )
I also think a programmer should be able to use the free function
to free memory that was allocated outside of a function or procedure
from within a procedure or function.
An example for it's need is:
With in a procedure and I want to free a memory pointer's
allocated memory. Reallocate a larger memory block and then reassign
that memory block to that same memory pointer. This at present can not
be done in Euphoria.
Bernie
4. Re: address of variable
Rob:
Correction, memory can be freed from within a function or procedure.
But, I want to be able to reassign a global pointer inside a procedure or
function.
Bernie
5. Re: address of variable
Bernie Ryan wrote:
>I think that a programmer should be able to store data in a
>global variable inside a procedure or function. ( I don't need to
>know the variables address )
Erm...you already *can* do this...
global object var
...
procedure or_function()
...
var = some_value
...
end procedure
>I also think a programmer should be able to use the free function
>to free memory that was allocated outside of a function or procedure
>from within a procedure or function.
atom addr
...
procedure one_procedure()
...
addr = allocate(number_of_bytes_needed)
...
end procedure
...
procedure another_procedure()
...
if addr then
...
free(addr)
end if
...
end procedure
>An example for it's need is:
> With in a procedure and I want to free a memory pointer's
>allocated memory. Reallocate a larger memory block and then reassign
>that memory block to that same memory pointer. This at present can not
>be done in Euphoria.
atom addr
addr = 0
...
procedure resize_memory_block()
...
free(addr)
...
addr = allocate(new_length)
...
end procedure
>Correction, memory can be freed from within a function or procedure.
>But, I want to be able to reassign a global pointer inside a procedure or
>function.
Okay, just put "global" in front of my "atom addr" in the example above.
Hep yadda,
Gabriel Boehme
----------
If we know what to look for, we may recognise it when it happens. Otherwise,
we see what we expect to see. That is, what we know in ourselves.
Robert Fripp
----------
6. Re: address of variable
On Thu, 16 Dec 1999 10:11:08 -0600, Boehme, Gabriel
<gboehme at POSTOFFICE.MUSICLAND.COM> wrote:
>Erm...you already *can* do this...
Gabriel:
It's probably something I'am overlooking but try this program:
include machine.e
global object var
var = allocate(4)
poke(var,123)
procedure foo()
? peek(var)
poke(var,456)
? peek(var)
end procedure
foo()
? peek(var)
Thanks Bernie
7. Re: address of variable
----- Original Message -----
From: Bernie Ryan <bwryan at PCOM.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, December 16, 1999 1:09 PM
Subject: Re: address of variable
> On Thu, 16 Dec 1999 10:11:08 -0600, Boehme, Gabriel
> <gboehme at POSTOFFICE.MUSICLAND.COM> wrote:
> >Erm...you already *can* do this...
>
> Gabriel:
> It's probably something I'am overlooking but try this program:
>
> include machine.e
>
> global object var
>
> var = allocate(4)
> poke(var,123)
>
> procedure foo()
> ? peek(var)
> poke(var,456)
An 8 bit memory location can hold more than 256 (or 255, depending on how
you call it, you know what i mean.) ? I know!, you are using one of those
new-fangled trinary cpus, right? How are they? I am guessing they do math
slower....
Kat
8. Re: address of variable
Bernie,
Your example returns the following output:
123
200
200
The reason for this is that 456 is outside a byte's 0-255 range, so you get
and_bits(456, #FF) = 200.
To store integers the way you seem to want to here (i.e., using 4 bytes),
use the following code instead:
include machine.e
global atom var
var = allocate(4)
poke(var, int_to_bytes(123))
procedure foo()
? bytes_to_int(peek({var,4}))
poke(var, int_to_bytes(456))
? bytes_to_int(peek({var,4}))
end procedure
foo()
? bytes_to_int(peek({var,4}))
This produces the following output:
123
456
456
Which is, I assume, what you wanted.
Hep yadda,
Gabriel Boehme
----------
The concern of the musician is music.
The concern of the professional musician is business.
Only become a professional musician if there is no other choice.
Robert Fripp
----------
9. Re: address of variable
On Thu, 16 Dec 1999 13:54:00 -0600, Kat <KSMiTH at PELL.NET> wrote:
>An 8 bit memory location can hold more than 256 (or 255, depending on how
>you call it, you know what i mean.) ? I know!, you are using one of those
>new-fangled trinary cpus, right? How are they? I am guessing they do math
>slower....
>
Kat:
DAHHH.. Should be poke4
PS. I know you are interested in scripting langauges.
Have you ever looked at NETRXX ( ibm languauge ) at their
web site. It allows you to write scripts in REXX for
controlling java across the net.
Thanks Kat
Bernie
10. Re: address of variable
On Thu, 16 Dec 1999 13:49:28 -0600, Boehme, Gabriel
<gboehme at POSTOFFICE.MUSICLAND.COM> wrote:
Gabriel:
Thanks Gabriel
I told you it was me, too many hours of programming :)
Bernie
11. Re: address of variable
Robert Craig wrote:
>Bernie Ryan writes:
>> Why is it so difficult for Euphoria to return the
>> address of a variable ?
>
>It isn't difficult. It's just a really bad idea
>for many other reasons. Here's my post on this
>subject from a few weeks ago...
>
>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.
Okay, I'll buy the internal format argument for the moment, but if we
cannot know the internal format, then don't we really need some
clear fixed structures and variables, if only for IO. At some point, we
need something other than peek and poke as fixed interfaces to the
outside world that use fixed forms of data with particular formats. I
would be perfectly happy if these fixed structures were limited in scope
to procedures in which the IO was done. It would be convenient if these
structures could be included in some manner with prefixing to allow
multiple occurrences. Peek and poke give us no names and actually
do have some dependencies as evidenced by the atom/integer discussion
that goes with their definition.
> - 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.
See above. There are ways to control this.
> - It would reveal proprietary information that might
> help the competition to make faster interpreters
> (Rebol 44x slower?, Perl 34x slower? Python 34x slower?)
I would have thought that the one thing that the Perl discussion would have
given us is surcease from this pointless non-comparison. Who cares?
Euphoria may or may not be faster than Perl/Rebol/Python/Visual whatever
in any particular piece of code. It probably is somewhat faster, but it
is most certainly overstated and of little significance to most of the
community according to their comments. The ease of coding and reading
appear to be uppermost in the minds of most of those who use Euphoria.
As time goes on and faster machines take over, this will be less and less
important. There will still be problems for which no interpretive or quasi-
intepretive language can provide an answer purely because of performance.
Proprietary paranoia appears to be solely your province.
> - 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.
We're talking about "call" interfaces here, not internal work. While in a
call, it is unlikely that a value will move around in memory because
Euphoria won't have control. If all references must be by value then
Euphoria should leave large things like screen IO completely alone
because those things are just too large to pass by anything other than
pointer. That leaves it as a script language that has only trivial ability
to handle major tasks. All that type of thing is now being done through
completely non-portable peek and poke rather than more easily modifiable
call interfaces because of this little limitation.
> - 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.
>
Sounds like an admission that Euphoria as it now stands is unable
to deal cleanly with things such as I have described above. It might be
noted that routine_id implements a pointer that is then passed as a value.
So much for consistency. Must be terrible when the real world intrudes.
Everett L.(Rett) Williams
rett at gvtc.com
12. Re: address of variable
Bernie Ryan wrote:
> DAHHH.. Should be poke4
DOH -- I forgot about poke4!
> I told you it was me, too many hours of programming :)
You and me both! 
Going off to re-read LIBRARY.DOC on poke4, peek4s & peek4u...
Hep yadda,
Gabriel Boehme
----------
Music is the cup which holds the wine of silence;
sound is that cup, but empty;
noise is that cup, but broken.
Robert Fripp
----------
13. Re: address of variable
----- Original Message -----
From: Everett Williams <rett at GVTC.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, December 16, 1999 2:22 PM
Subject: Re: address of variable
> Robert Craig wrote:
>
> >Bernie Ryan writes:
> >> Why is it so difficult for Euphoria to return the
> >> address of a variable ?
> >
> >It isn't difficult. It's just a really bad idea
> >for many other reasons. Here's my post on this
> >subject from a few weeks ago...
> >
>
> >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.
>
> Okay, I'll buy the internal format argument for the moment, but if we
> cannot know the internal format, then don't we really need some
> clear fixed structures and variables, if only for IO.
Well three of us are using socks to talk to the outside world, and we send
and recieve strings/sequences to do it. And somewhere i saw an assy language
script that accepts sequences to send to serial/parallel ports. Then there
is the interface to sound cards someone wrote, and an interface to a video
card for different modes for games. And the on_mouse is done. David has
interfaced with Win32lib and dos32lib(?). And Eu-managed screen buffering is
done. What is missing that you want to do? Can you show us a Eu script that
fails because of something Eu cannot do?
>
> > - It would reveal proprietary information that might
> > help the competition to make faster interpreters
> > (Rebol 44x slower?, Perl 34x slower? Python 34x slower?)
>
> I would have thought that the one thing that the Perl discussion would
have
> given us is surcease from this pointless non-comparison. Who cares?
Me, for one. Mirc is even easier to code in, it has goto and string
comparisons,, and heck, i can make strings that i don't know the names to
and use them at runtime,, and it self modifies, etc,,, but it pours as slow
as glass, and we all know glass is a liquid.... So i paid for a complete
edition of Eu, to get that speed and ease of coding. It was that important
to me,, as of the 10th of Dec, i had $19 to last me the month, i'm not rich.
> > - 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.
>
> We're talking about "call" interfaces here, not internal work. While in a
> call, it is unlikely that a value will move around in memory because
> Euphoria won't have control.
You have something of a point here, but then there is windoze's nasty habit
of paging things around, right out from under running applications.
> > - 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.
> >
> Sounds like an admission that Euphoria as it now stands is unable
> to deal cleanly with things such as I have described above. It might be
> noted that routine_id implements a pointer that is then passed as a value.
> So much for consistency. Must be terrible when the real world intrudes.
Everett, you gotta know that when an atom in a sequence takes up 4 bytes
that 3 of those bytes have important data about the other byte's place in
the world,,, and you shouldn't mess with those 3 bytes. Eu has more than one
poke(), is there something besides that ( and the things i mentioned above )
that you wish to do?
Kat
14. Re: address of variable
Everett Williams wrote:
[mega snippage]
> Must be terrible when the real world intrudes.
I'm sorry, but this statement of yours *really* made me angry. You, who only
*ever* argue about what Euphoria should or shouldn't have based on your own
*abstract* and *theoretical* ideas, are going to lecture *us* on the "real
world"?!?!
Here's my suggestion, for what it's worth. If you want these "problems" of
yours addressed, post some "real world" code examples which actually
demonstrate what you're talking about. You might be surprised by the helpful
replies and "real world" solutions you'll receive in return.
Yadda yadda,
Gabriel Boehme
----------
When we have nothing to say, better to say nothing.
When we have nothing to say, it is very hard to say nothing.
Robert Fripp
----------
15. Re: address of variable
Kat wrote:
>> >
>> Sounds like an admission that Euphoria as it now stands is unable
>> to deal cleanly with things such as I have described above. It might be
>> noted that routine_id implements a pointer that is then passed as a value.
>> So much for consistency. Must be terrible when the real world intrudes.
>
>Everett, you gotta know that when an atom in a sequence takes up 4 bytes
>that 3 of those bytes have important data about the other byte's place in
>the world,,, and you shouldn't mess with those 3 bytes. Eu has more than one
>poke(), is there something besides that ( and the things i mentioned above )
>that you wish to do?
>
>Kat
Actually, I was following my license and not checking such things...not that
I doubt what you are saying. But thanks for making my point. A quick look
at the DBF-eng code from the archive will show you what absolute gyrations
one must go to, to deal with externally formatted data. This only deals with
DBF III files. A few simple structures could get rid of about 90% of that
code. I'm not asking for access to those precious internal formats. I'm
asking for some way to deal with structured external data without doing
things that relate only to Euphoria's internal peculiarities. The problem is
on the way out. Unless, the external data is dealt with entirely as meta-data
within Euphoria, it becomes necessary to understand what you are not
supposed to know about it to get it back into an external form. Actually,
not even that will suffice unless one uses poke and it's variants. Every
thing else violates that fact that you aren't supposed "know" about the
internal format of anything. This gets into "the Emperor's new clothes"
type of discussion. Wink, wink..nod, nod..we don't really know what
those internal variables look like. Except the IO routines do "sort of"
without really talking about it...or really documenting it for that matter.
Since there is already a huge amount of nodding and winking going on
in ASCII text handling for strings, I "bought" your argument on that one.
Of course, double byte text will break the "unprintable" out of that.
Structured data has no such equivalent and really can't have if we
really believe the words of our esteemed author. Actually, if you follow
his logic, you really can't have native "Euphoria IO". If variable form is
subject to change, then who could ever know what was written out and
how to read it back in.
Everett L.(Rett) Williams
rett at gvtc.com
