VARIABLE!
Wil Baden
> VARIABLE!
> motivation:
> Changing all occurences of the word VARIABLE to VARIABLE!
> is an easy way to make FIG-Forth-ish variables ANS-compatible.
> description:
> The old forth implementations used an initializing
> value for the word VARIABLE but new ansi standard
> has left it out. This is often inconvenient for
> programmers, but the newer ansi form has some
> benefits for ROM-able forth system (where the
> VARIABLE goes into some kind of BSS section).
> In a discussion on c.l.f. it turned out that it
> is not quite easy to attach an initializing
> value after its declaration, the ansi words of
> SEARCH-WORDLIST and their kind are just not
> enough (even CURRENT is not in the standard).
Why not?
How about:
: VARIABLE! ( n "name" -- )
>IN @ VARIABLE
>IN ! PARSE-WORD ( str len)
GET-CURRENT SEARCH-WORDLIST DROP ( xt)
EXECUTE ! ;
-------------------------------
> ...
> Philip Preston wrote:
> > Why not ...
> >
> > : VARIABLE! ( x "<spaces>name" -- ) CREATE , ;
I agree. But simply replace FIG-Forth n VARIABLE name with:
CREATE name n ,
In target compilation a distinction is made between initialized data
and uninitialized data.
VARIABLE is for uninitialized data; CREATE for initialized data.
In my work this is a distinction without a difference, but it's easy
to do for documentation.
Target compilation also may have n BUFFER: name for uninitialized
areas.
In my work I also find this nice for documentation.
: BUFFER: ( n "name" -- ) dup CREATE ALLOT ;
--
Wil Baden Costa Mesa, California Per neil...@earthlink.net
Wil Baden
: BUFFER: ( n "name" -- ) CREATE ALLOT ;
Elizabeth D. Rather
> From: http://forth.sourceforge.net/word/
>
> > VARIABLE!
>
> > motivation:
>
> > Changing all occurences of the word VARIABLE to VARIABLE!
> > is an easy way to make FIG-Forth-ish variables ANS-compatible.
>
> > description:
>
> > The old forth implementations used an initializing
> > value for the word VARIABLE but new ansi standard
> > has left it out.
Actually, that change was made in FORTH-83.
> How about:
>
> : VARIABLE! ( n "name" -- )
> >IN @ VARIABLE
> >IN ! PARSE-WORD ( str len)
> GET-CURRENT SEARCH-WORDLIST DROP ( xt)
> EXECUTE ! ;
>
> -------------------------------
>
> > ...
>
> > Philip Preston wrote:
> > > Why not ...
> > >
> > > : VARIABLE! ( x "<spaces>name" -- ) CREATE , ;
>
> I agree. But simply replace FIG-Forth n VARIABLE name with:
>
> CREATE name n ,
>
> In target compilation a distinction is made between initialized data
> and uninitialized data.
Yes, but I think that would bite Wil's VARIABLE! as well, since
at compile time you have no access to uninitialized data (by
definition).
In the proposed cross-compiler addendum to ANS Forth, whether
VARIABLE is in initialized or uninitialized data is controlled by
a switch, but uninitialized is the default (at least in our systems).
Practically speaking, if you are on a system that permits
initializing VARIABLEs at compile time, there's no reason
not to do so (as long as you remember it's an environmental
dependency and not guaranteed portable).
Cheers,
Elizabeth
h-peter recktenwald
Wil Baden <neil...@earthlink.net> wrote:
> From: http://forth.sourceforge.net/word/
>
> > VARIABLE!
>
> > motivation:
>
> > Changing all occurences of the word VARIABLE to VARIABLE!
> > is an easy way to make FIG-Forth-ish variables ANS-compatible.
[...]
> How about:
>
> : VARIABLE! ( n "name" -- )
> >IN @ VARIABLE
> >IN ! PARSE-WORD ( str len)
> GET-CURRENT SEARCH-WORDLIST DROP ( xt)
> EXECUTE ! ;
>
> -------------------------------
wouldn't something that way be sufficient?
: VARIABLE! VARIABLE LAST @ >BODY ! ; ( or "LATEST" )
regards,
hp
--
mailto:ph...@snafu.de - h.-peter recktenwald, berlin - +49 30 85967858
Linux,Assembly,Forth: http://home.snafu.de/phpr/index-lx.shtml (en,de)
fight abusive software patents
http://petition.eurolinux.org/pr/pr17.html
Julian V. Noble
Many implementations of VARIABLE initialize it
with 0 for safety. In WATFOR and other similar
systems (it was a fast-compiling Fortran) the
variables were initialized to something that would
cause an abort if you retrieved their contents
without first initializing them. I think it was
a number with a wrong parity bit. I fear nothing
similar is possible on modern machines because
there is no longer an automatic parity check
(memory having become more reliable).
Does anyone have any notions on whether it would be
possible on modern hardware to do what used to be
commonplace?
--
Julian V. Noble
Professor of Physics
j...@virginia.edu
"Science knows only one commandment: contribute to science."
-- Bertolt Brecht, "Galileo".
Guido Draheim
>
> Many implementations of VARIABLE initialize it
> with 0 for safety. In WATFOR and other similar
> systems (it was a fast-compiling Fortran) the
> variables were initialized to something that would
> cause an abort if you retrieved their contents
> without first initializing them. I think it was
> a number with a wrong parity bit. I fear nothing
> similar is possible on modern machines because
> there is no longer an automatic parity check
> (memory having become more reliable).
>
> Does anyone have any notions on whether it would be
> possible on modern hardware to do what used to be
> commonplace?
>
or ECC bit. You could only use some very very
serious programming of an MMU - just make the
memory-location in-accessible. As soon as the first
access-trap comes in, check if it is a READ and
fail if it did access a memory location without a
prior WROTE, but if it is WRITE then let it pass and
memorize the fact. if everything is eaten up, then
enable readwrite-mode for the page, so it doesn't
trap on every access. Well, in most cases it is
seriously overdone ;-) ... in most of the cases,
one can check the program with having the defaults
set to MIN_INT (signed value) instead of zero.
cheers, guido
Gary Chanson
"Julian V. Noble" <j...@virginia.edu> wrote in message
news:3CA686D9...@virginia.edu...
>
> Many implementations of VARIABLE initialize it
> with 0 for safety. In WATFOR and other similar
> systems (it was a fast-compiling Fortran) the
> variables were initialized to something that would
> cause an abort if you retrieved their contents
> without first initializing them. I think it was
> a number with a wrong parity bit. I fear nothing
> similar is possible on modern machines because
> there is no longer an automatic parity check
> (memory having become more reliable).
>
> Does anyone have any notions on whether it would be
> possible on modern hardware to do what used to be
> commonplace?
Possibly. Some modern memory does do error checking, but not a simple
parity bit, and a detected error would typically be treated as an
unrecoverable error.
On some architectures, it might be possible to use the memory manager to
trap access by setting the data memory to generate a page fault, but the
write operation would have to clear this before setting it. It might also
require setting aside a whole page for each variable.
--
-GJC
-gch...@TheWorld.com
-War is the last resort of the incompetent.
Marcel Hendrix
Julian V. Noble wrote:
[ detect non-initialized variable trough hardware ]
> Does anyone have any notions on whether it would be possible on modern
> hardware to do what used to be commonplace?
Modern Fortran compilers detect attempts to write to a constant with MMU
tricks. Corrupting constants seems to be a common bug caused by calling
functions with a constant instead of a variable. More MMU / debug register
tricks might be possible. A software approach with self-modifying code looks
much easier to me.
-marcel
Jerry Avins
I've long felt that the minimum integer in a twos-complement system
ought to be treated as NAN. Only the complexity that this would add to
hardware stands in the way. Of course, initializing IEEE floating-point
variables to NAN is (conceptually) simple.
Jerry
--
Engineering is the art of making what you want from things you can get.
-----------------------------------------------------------------------
Chris Jakeman
>"Julian V. Noble" wrote:
>> Many implementations of VARIABLE initialize it
>> with 0 for safety. In WATFOR and other similar
>> systems (it was a fast-compiling Fortran) the
>> variables were initialized to something that would
>> cause an abort if you retrieved their contents
>> without first initializing them. I think it was
>> a number with a wrong parity bit. I fear nothing
>> similar is possible on modern machines because
>> there is no longer an automatic parity check
>> (memory having become more reliable).
>
>I've long felt that the minimum integer in a twos-complement system
>ought to be treated as NAN. Only the complexity that this would add to
>hardware stands in the way. Of course, initializing IEEE floating-point
>variables to NAN is (conceptually) simple.
Well said, Julian. Automatically initialising to 0 is a bad idea as it
tends to hide problems.
Some time back I advocated on this newsgroup the opposite;
initialising a variable to a value that is likely to cause trouble at
the earliest possible stage.
I advocated -32767 for this "troublesome" value, being a number that
can be represented on all standard systems and most likely to cause
trouble.
Bye for now ____/ / __ / / / / /
/ / / _/ / / / /
Chris Jakeman __/ / / __ / / /_/
/ / / / / / / \
[To reply, please __/ __/ ____/ ___/ __/ _\
unspam my address]
Forth Interest Group United Kingdom
Voice +44 (0)1733 753489 chapter at http://www.fig-uk.org
Jerry Avins
Chris,
You assume 16 bits, here, I presume. -32768 would be better yet, no?
Removing it from the number set would leave that set symmetrical.
Jeff Fox
> Some time back I advocated on this newsgroup the opposite;
> initialising a variable to a value that is likely to cause trouble at
> the earliest possible stage.
If one can initialize the variables in a system why not
initialize them to the proper value and avoid all the errors?
best wishes,
Jeff Fox
Jerry Avins
The proper value isn't always known at compile time. A problem arises
from a fetch before a store; clearly a bug. The point of initializing to
"invalid" is catching bugs, not fixing them.
Trey Boudreau
> Jeff Fox wrote:
>>
>> Chris Jakeman wrote:
>> > Some time back I advocated on this newsgroup the opposite;
>> > initialising a variable to a value that is likely to cause trouble at
>> > the earliest possible stage.
>>
>> If one can initialize the variables in a system why not
>> initialize them to the proper value and avoid all the errors?
>>
>> best wishes,
>> Jeff Fox
>
> The proper value isn't always known at compile time. A problem arises
> from a fetch before a store; clearly a bug. The point of initializing to
> "invalid" is catching bugs, not fixing them.
>
From the web page:
"Valgrind tracks each byte of memory in the original program with nine status
bits, one of which tracks addressibility of that byte, while the other eight
track the validity of the byte. As a result, it can detect the use of single
uninitialised bits, and does not report spurious errors on bitfield
operations."
It doesn't come without performance costs, but it sure will come in handy when
tracking down memory bugs.
> Jerry
-- Trey
Rick Hohensee
Constants are trivial; a read-only loader section, which your
code section usually is in unix. osimplay executables aren't,
but such things are available.
As to improperly initialized variables, there's a
"signalling NAN" but I just saw that for the first time
in 387INTEL.TXT. I guess it traps. That works for floats.
It also works for ints as floats, but probably not ints
as ints on 387. Those can't disallow the NAN bit pattern,
which all bits on in sign and exponent.
But again, I just scanned the huge textfile for the first time.
It looks like what you want is available for floats though.
Rick Hohensee
Jerry Avins
For tracking down bugs, Forth makes it easy to redefine VARIABLE to
include a validity cell and to attach behavior to variable names that
cause a modified @ to check it. For tracking down bugs, Forth makes it
easy to redefine array generation and access to record and check bounds.
The problem is not finding bugs that have bitten, but finding ways to
make them bite.