VARIABLE CONSTANT...VALUE ???
Bruce R. McFarling
"M.L.Gassanenko" <m...@iias.spb.su> wrote:
>ve...@micronet.fr (Jean-Francois Brouillet) wrote in <verec-17079...@pppa128.micronet.fr>:
>
>>Using a ``typical'' (threaded) Forth interpreter, one can code:
>>
>>: VARIABLE CREATE 0 , DOES> ; ( -- )
>>: CONSTANT CREATE , DOES> @ ; ( x -- ) \ ( -- n)
>>: VALUE CREATE , DOES> @ ; ( x -- ) \ ( -- n)
>>: TO ' >BODY ! ;
>>
>>Even in the context of RAM/ROM system I can't see the need for those
>>redundant words : a VARIABLE in ROM is hardly...well a variable, and
>
> sometimes the ROM things that behave like variables *are* useful,
> because they enable you to use the same code that worked for RAM
> without any modifications (although you cannot change them while
> the program runs, you do not have to eliminate @'s after their
> names).
This is getting off the track. The point is that in a
RAM/ROM system, you *wouldn't define VARIABLE that way*. A
VARIABLE would likely be a constant pointer to a location in
RAM. Returning a constant value, a pointer to a cell in dataspace,
or a 'mutable constant' value can be implemented in a variety
of ways, and they have standard names and semantics so you don't
have to worry about implementation details.
>> ... a VALUE is nothing more than a variable with a special
>> syntax to store to. Moreover, as seen above, in many
>> implementations a CONSTANT does compile to exactly the
>> same code than a VALUE...
Of course, the rest of this was on-track: whether
or not CONSTANT compiles to the same code as VALUE, an
implementer can assume that you are using VALUE because
you know you will be fetching the information a lot more
than you will storing it, and can optimize VALUE for
information retrieval. For example, the quickest way
to get info onto the stack in a 6502 DTC is to have a
primitive doCONSTANT that expects the value in the A and
Y registers, and implement constant as:
lda #hi_byte
ldy #lo_byte
jmp doCONSTANT
If that is in RAM, VALUE can do the same thing, but TO
has to split up the value by byte and know where to put
the individual pieces. On the other hand, if that is in
ROM, VALUE is quickest with it's own primitive that takes
an address in the same register and fetches from that
address to the stack (assume an X-indexed stack):
lda #>val_address
ldy #<val_address
jmp doVALUE
..
doVALUE: sta W+1
sty W
dex
dex
ldy #0
lda (W),y
sta sl,x
iny
lda (W),y
sta sh,x
jmp NEXT
which is substantially faster than shuffling the address onto
the stack and the shuffling it off the stack again for the fecth.
>>
>>So what's the point of having all of this stuff ?
>>Is history alone responsible for this ?
>>Or are there more genuine reasons I fail to notice ?
SO:
> The reason is that implementors are allowed to use any
> perverted techniques to optimize their code for speed/size
> or whatever.
Is exactly right. Assuming the required resources
are there, the implmenter can work around the peculiarities
of the processor or host OS and the application can just take
it for granted that a VALUE will be either a little or a lot
faster getting mutable information to the stack than a VARIABLE
will be. And a VARIBLE will return a dataspace address that
can be used immediately or saved itself for later use.
--
Virtually,
Bruce R. McFarling, Newcastle, NSW
ec...@cc.newcastle.edu.au
Jean-Francois Brouillet
Hi all.
Using a ``typical'' (threaded) Forth interpreter, one can code:
: VARIABLE CREATE 0 , DOES> ; ( -- )
: CONSTANT CREATE , DOES> @ ; ( x -- ) \ ( -- n)
: VALUE CREATE , DOES> @ ; ( x -- ) \ ( -- n)
: TO ' >BODY ! ;
Even in the context of RAM/ROM system I can't see the need for those
redundant words : a VARIABLE in ROM is hardly...well a variable, and
and CONSTANT would do much better (IMHO)
a VALUE is nothing more than a variable with a special syntax to store to.
Moreover, as seen above, in many implementations a CONSTANT does compile
to exactly the same code than a VALUE...
So what's the point of having all of this stuff ?
Is history alone responsible for this ?
Or are there more genuine reasons I fail to notice ?
Puzzled,
--
Jean-Francois Brouillet ve...@micronet.fr
Macintosh Software Developer
M.L.Gassanenko
>Using a ``typical'' (threaded) Forth interpreter, one can code:
>
>: VARIABLE CREATE 0 , DOES> ; ( -- )
>: CONSTANT CREATE , DOES> @ ; ( x -- ) \ ( -- n)
>: VALUE CREATE , DOES> @ ; ( x -- ) \ ( -- n)
>: TO ' >BODY ! ;
>
>Even in the context of RAM/ROM system I can't see the need for those
>redundant words : a VARIABLE in ROM is hardly...well a variable, and
sometimes the ROM things that behave like variables *are* useful, because
they enable you to use the same code that worked for RAM without any
modifications (although you cannot change them while the program runs,
you do not have to eliminate @'s after their names).
In addition, you sometimes have values that can be changed and some that cannot,
but you do not remember which one is a CONSTANT (and do not want to do it).
In this case uniformity is preferrable.
>and CONSTANT would do much better (IMHO)
>
>a VALUE is nothing more than a variable with a special syntax to store to.
>Moreover, as seen above, in many implementations a CONSTANT does compile
>to exactly the same code than a VALUE...
>
>So what's the point of having all of this stuff ?
>Is history alone responsible for this ?
>Or are there more genuine reasons I fail to notice ?
The reason is that implementors are allowed to use any perverted techniques
to optimize their code for speed/size or whatever.
Your definition (provided that you enhance TO to support compilation state)
*must* run on *any* ANS Forth. But implementors may use any tricks to implement
e.g. fast constants or variables.
E.g. in F32/16 (a 32-bit Forth for 8086) I can define constant either
in a classical way or like a CODE definition that leaves the value in TOS.
Sort of:
: constant ( x -- )
10000h /mod ( lo hi )
>r >r ( r: hi lo )
code [ also asm ]
push tos.h
push tos.l
mov tos.h, # r>
mov tos.l, # r>
next,
end-code
[ previous ]
;
At the same time, I may wish VALUEs not to be so exoptimized.
Constants, values, variables are not guaranteed to have a data field.
They are allowed to use RAM to hold their values, but
this memory must be in the data space only for variables.
(BTW, the ANS TO for such VALUEs looks awful:
: to
' >body
state @
if postpone literal postpone !
else !
then
; immediate
)
--
Michael L. Gassanenko
m...@iias.spb.su
CRepublic
In article <verec-17079...@pppa128.micronet.fr>, ve...@micronet.fr
(Jean-Francois Brouillet) writes:
>Using a ``typical'' (threaded) Forth interpreter, one can code:
>
>: VARIABLE CREATE 0 , DOES> ; ( -- )
>: CONSTANT CREATE , DOES> @ ; ( x -- ) \ ( -- n)
>: VALUE CREATE , DOES> @ ; ( x -- ) \ ( -- n)
>: TO ' >BODY ! ;
>
>Even in the context of RAM/ROM system I can't see the need for those
>redundant words : a VARIABLE in ROM is hardly...well a variable, and
>and CONSTANT would do much better (IMHO)
>
>a VALUE is nothing more than a variable with a special syntax to store
to.
>Moreover, as seen above, in many implementations a CONSTANT does compile
>to exactly the same code than a VALUE...
>
>So what's the point of having all of this stuff ?
>Is history alone responsible for this ?
>Or are there more genuine reasons I fail to notice ?
I'm no expert but my gess would be readableity.
Hans-Peter Recktenwald
ve...@micronet.fr (Jean-Francois Brouillet) wrote:
>Hi all.
>Using a ``typical'' (threaded) Forth interpreter, one can code:
>: VARIABLE CREATE 0 , DOES> ; ( -- )
>: CONSTANT CREATE , DOES> @ ; ( x -- ) \ ( -- n)
>: VALUE CREATE , DOES> @ ; ( x -- ) \ ( -- n)
>: TO ' >BODY ! ;
>Even in the context of RAM/ROM system I can't see the need for those
>redundant words : a VARIABLE in ROM is hardly...well a variable, and
>and CONSTANT would do much better (IMHO)
>a VALUE is nothing more than a variable with a special syntax to store to.
>Moreover, as seen above, in many implementations a CONSTANT does compile
>to exactly the same code than a VALUE...
>So what's the point of having all of this stuff ?
>Is history alone responsible for this ?
>Or are there more genuine reasons I fail to notice ?
>Puzzled,
Julian V. Noble
There are two reasons for so-called multiple code field words.
First is speed cum portability: indirect-threaded Forths allow
you to change the value of a CONSTANT via
3 CONSTANT three three . 3 ok
5 ' three ! three . 5 ok
Using a CONSTANT rather than a VARIABLE is faster in high level
code: saying
i
3 CONSTANT three
: name ..... three ..... ;
is faster and uses less compiled code than saying
VARIABLE three'
: name' .... three' @ .... ;
If you rarely have to change a CONSTANT, doing it that way is faster.
But this is not portable--it fails with direct threading, e.g.
So there is a need for a portable way to combine the speed of a
CONSTANT with the mutability of a VARIABLE. This is a VALUE.
The second reason for VALUE is indeed readability. Having to in-
clude a @ everytime a VARIABLE is invoked fills the code with
visual clutter and noise. Being able to omit "noise" words such
as @, R@, >R and R> greatly increases the clarity of one's code.
--
Julian V. Noble
j...@virginia.edu