Hi! i'm starting to learn forth and i'm using gforth and win32forth with the starting forth book.
in the book there is an exercise that suggests doing a word that resets the stack (231--123), however I can do the exercise in win32forth but not in gforth which gives me a stack underflow error.
And in both I tried to create a syntactic sugar word for >R and they gave me an error too.
Why did these errors happen?
thanks.

On 27/01/2022 15:54, fabianor...@gmail.com wrote:
> Hi! i'm starting to learn forth and i'm using gforth and win32forth with the starting forth book.
> in the book there is an exercise that suggests doing a word that resets the stack (231--123), however I can do the exercise in win32forth but not in gforth which gives me a stack underflow error.
> And in both I tried to create a syntactic sugar word for >R and they gave me an error too.
> Why did these errors happen?
> thanks.

What was your code? It sounds like you've used >R non-portably.

"fabianor...@gmail.com" <fabianorezende26@gmail.com> writes:
>Hi! i'm starting to learn forth and i'm using gforth and win32forth with the starting forth book.
>in the book there is an exercise that suggests doing a word that resets the stack (231--123), however I can do the exercise in win32forth but not in gforth which gives me a stack underflow error.
>And in both I tried to create a syntactic sugar word for >R and they gave me an error too.
>Why did these errors happen?

As dxforth writes, we need to know exactly what you tried (what you
typed into Gforth, and what error you got) to answer this question.

For stack underflow, there is one generality I can state: gforth (the
debugging engine) reports almost* every stack underflow, most other
Forth systems (including gforth-fast) are less pedantic. E.g.,
starting with an empty stack,

1 swap .

does not report an error on gforth-fast, iforth, lxf, SwiftForth, or
VFX, but reports a stack underflow in gforth.

For the second case, an unknown piece of code producing an unknown
error, I cannot even state generalities.

*There is a relatively newfangled optimization in development Gforth
that compiles "0 +" into nothing, and as a result won't report a stack
underflow when that code is executed starting with an empty stack.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 27/01/2022 19:48, Anton Ertl wrote:
>
> *There is a relatively newfangled optimization in development Gforth
> that compiles "0 +" into nothing, and as a result won't report a stack
> underflow when that code is executed starting with an empty stack.

gforth-fast 2020-07-09 does that. What cases prompted you to add it?
I'm aware +FIELD optimizes the 0 offset case but that's handled separately (?)

Em quinta-feira, 27 de janeiro de 2022 às 02:16:47 UTC-3, dxforth escreveu:
> On 27/01/2022 15:54, fabianor...@gmail.com wrote:
> > Hi! i'm starting to learn forth and i'm using gforth and win32forth with the starting forth book.
> > in the book there is an exercise that suggests doing a word that resets the stack (231--123), however I can do the exercise in win32forth but not in gforth which gives me a stack underflow error.
> > And in both I tried to create a syntactic sugar word for >R and they gave me an error too.
> > Why did these errors happen?
> > thanks.
>
> What was your code? It sounds like you've used >R non-portably.
: my-word >R ;
1 my-word
*the terminal*:21:7: error: invalid memory adress
1 >>>my-word<<<
Back-trace:
*Terminal*:2:8 0 $6FFFFF877200 ;s

"fabianor...@gmail.com" <fabianorezende26@gmail.com> writes:
>: my-word >R ;
>1 my-word
>*the terminal*:21:7: error: invalid memory adress

This pushes 1 on the return stack and then tries to use it as a return
address (i.e., return to address 1). Address 1 is probably no valid
address on your system, so you get an "invalid memory address" error.

What did you want to achieve?

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

Em quinta-feira, 27 de janeiro de 2022 às 10:13:20 UTC-3, Anton Ertl escreveu:
> "fabianor...@gmail.com" <fabianor...@gmail.com> writes:
> >: my-word >R ;
> >1 my-word
> >*the terminal*:21:7: error: invalid memory adress
> This pushes 1 on the return stack and then tries to use it as a return
> address (i.e., return to address 1). Address 1 is probably no valid
> address on your system, so you get an "invalid memory address" error.
>
> What did you want to achieve?
> - anton
> --
> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> New standard: http://www.forth200x.org/forth200x.html
> EuroForth 2021: https://euro.theforth.net/2021
wasn't it just pushing it to the return stack?

dxforth <dxforth@gmail.com> writes:
>On 27/01/2022 19:48, Anton Ertl wrote:
>>
>> *There is a relatively newfangled optimization in development Gforth
>> that compiles "0 +" into nothing, and as a result won't report a stack
>> underflow when that code is executed starting with an empty stack.
>
>gforth-fast 2020-07-09 does that. What cases prompted you to add it?
>I'm aware +FIELD optimizes the 0 offset case but that's handled separately (?)

In development Gforth +FIELD does not handle 0 separately, but leaves
it to the code generator OPT+- for + and - to handle the 0 case.
Handling it in OPT+- is just as much effort, but is more general.
Here's the code:

1) For the code generator for compiling a field, without special
handling of 0:

: field+, >body @ lit, postpone + ;

2) For OPT+-, with special handling of 0:

: opt+- {: xt: op -- :}
lits# 1 = if
0 lits> op ?dup-if
['] lit+ peephole-compile, , then
exit then
action-of op fold2-1 ;
' opt+- folds + -

The handling of 0 is the ?DUP-IF and its THEN. Leave these two words
away, and 0 + compiles to LIT+ with a 0 immediate operand.

Here's the explanation for the rest: OP is the word being compiled (+
or -). The first IF checks if there is exactly one literal on the
(literal) stack (for optimizing to use LIT+); if not, the general
constant folder fold2-1 for words with 2 cells input and one cell
output is used: if there are at least two operands it applies op to
compute a new literal, otherwise it just compiles the literals from
the literal stack (there can be none, given that we already filtered
out the 1-literal case earlier) and OP.

I don't think there were any cases that prompted us to go this way,
just the general principle of not unnecessarily restricting the scope
of dealing with 0.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 28/01/2022 00:20, fabianor...@gmail.com wrote:
> Em quinta-feira, 27 de janeiro de 2022 às 10:13:20 UTC-3, Anton Ertl escreveu:
>> "fabianor...@gmail.com" <fabianor...@gmail.com> writes:
>> >: my-word >R ;
>> >1 my-word
>> >*the terminal*:21:7: error: invalid memory adress
>> This pushes 1 on the return stack and then tries to use it as a return
>> address (i.e., return to address 1). Address 1 is probably no valid
>> address on your system, so you get an "invalid memory address" error.
>>
>> What did you want to achieve?
>> - anton
>> --
>> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
>> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>> New standard: http://www.forth200x.org/forth200x.html
>> EuroForth 2021: https://euro.theforth.net/2021
> wasn't it just pushing it to the return stack?

Yes but the system is also using the return stack while you're typing!
The return stack is primarily for its use - not yours.

Em quinta-feira, 27 de janeiro de 2022 às 10:50:45 UTC-3, dxforth escreveu:
> On 28/01/2022 00:20, fabianor...@gmail.com wrote:
> > Em quinta-feira, 27 de janeiro de 2022 às 10:13:20 UTC-3, Anton Ertl escreveu:
> >> "fabianor...@gmail.com" <fabianor...@gmail.com> writes:
> >> >: my-word >R ;
> >> >1 my-word
> >> >*the terminal*:21:7: error: invalid memory adress
> >> This pushes 1 on the return stack and then tries to use it as a return
> >> address (i.e., return to address 1). Address 1 is probably no valid
> >> address on your system, so you get an "invalid memory address" error.
> >>
> >> What did you want to achieve?
> >> - anton
> >> --
> >> M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
> >> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
> >> New standard: http://www.forth200x.org/forth200x.html
> >> EuroForth 2021: https://euro.theforth.net/2021
> > wasn't it just pushing it to the return stack?
> Yes but the system is also using the return stack while you're typing!
> The return stack is primarily for its use - not yours.
Thanks

"fabianor...@gmail.com" <fabianorezende26@gmail.com> writes:
>Em quinta-feira, 27 de janeiro de 2022 =C3=A0s 10:13:20 UTC-3, Anton Ertl e=
>screveu:
>> "fabianor...@gmail.com" <fabianor...@gmail.com> writes:=20
>> >: my-word >R ;=20
>> >1 my-word=20
>> >*the terminal*:21:7: error: invalid memory adress
....
>wasn't it just pushing it to the return stack?

The call to MY-WORD pushes a return address (which points to somewhere
in the text interpreter in this case) on the return stack, then >R
pushes 1 on the return stack, then the return from MY-WORD should
happen (using the word ";S", which you see in the backtrace), but
instead of the return address it finds 1 on the return stack, and
tries to return there.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 27/01/2022 08:48, Anton Ertl wrote:
> For stack underflow, there is one generality I can state: gforth (the
> debugging engine) reports almost* every stack underflow, most other
> Forth systems (including gforth-fast) are less pedantic. E.g.,
> starting with an empty stack,
>
> 1 swap .
>
> does not report an error on gforth-fast, iforth, lxf, SwiftForth, or
> VFX, but reports a stack underflow in gforth.

--
Gerry

On 27/01/2022 08:48, Anton Ertl wrote:
> For stack underflow, there is one generality I can state: gforth (the
> debugging engine) reports almost* every stack underflow, most other
> Forth systems (including gforth-fast) are less pedantic. E.g.,
> starting with an empty stack,
>
> 1 swap .
>
> does not report an error on gforth-fast, iforth, lxf, SwiftForth, or
> VFX, but reports a stack underflow in gforth.

My system doesn't report stack underflow for 1 SWAP and this triggered
me into investigating a bit further. 1 SWAP is actually safe for a small
underflow because there are a few guard cells below the stack so that
simple underflow doesn't cause a system crash. 1 SWAP actually works.
The integer swapped under the stack is actually accessible - I never
thought about this before.

e.g. (assume an empty stack)
1234 swap over . \ displays 1234
1 2 3 4 5 depth pick . \ displays 1234

Similarly with other stack manipulation words.

This is also the case with SwiftForth, VFX Forth, wf32 Forth.
Yet another way to misuse Forth!

This is potentially useful if you want to stash some data for re-entrant
code without having to maintain it near the top of the stack.

--
Gerry

Gerry Jackson schrieb am Donnerstag, 27. Januar 2022 um 21:39:10 UTC+1:
> On 27/01/2022 08:48, Anton Ertl wrote:
> > For stack underflow, there is one generality I can state: gforth (the
> > debugging engine) reports almost* every stack underflow, most other
> > Forth systems (including gforth-fast) are less pedantic. E.g.,
> > starting with an empty stack,
> >
> > 1 swap .
> >
> > does not report an error on gforth-fast, iforth, lxf, SwiftForth, or
> > VFX, but reports a stack underflow in gforth.
> My system doesn't report stack underflow for 1 SWAP and this triggered
> me into investigating a bit further. 1 SWAP is actually safe for a small
> underflow because there are a few guard cells below the stack so that
> simple underflow doesn't cause a system crash. 1 SWAP actually works.
> The integer swapped under the stack is actually accessible - I never
> thought about this before.
>
> e.g. (assume an empty stack)
> 1234 swap over . \ displays 1234
> 1 2 3 4 5 depth pick . \ displays 1234
>
> Similarly with other stack manipulation words.
>
> This is also the case with SwiftForth, VFX Forth, wf32 Forth.
> Yet another way to misuse Forth!
>
> This is potentially useful if you want to stash some data for re-entrant
> code without having to maintain it near the top of the stack.
>

I consider this array-out-of-bounds usage as poor and potentially dangerous practice.
Eg Java would throw a runtime exception.

On 28/01/2022 09:29, minf...@arcor.de wrote:
> Gerry Jackson schrieb am Donnerstag, 27. Januar 2022 um 21:39:10 UTC+1:
>> On 27/01/2022 08:48, Anton Ertl wrote:
>> > For stack underflow, there is one generality I can state: gforth (the
>> > debugging engine) reports almost* every stack underflow, most other
>> > Forth systems (including gforth-fast) are less pedantic. E.g.,
>> > starting with an empty stack,
>> >
>> > 1 swap .
>> >
>> > does not report an error on gforth-fast, iforth, lxf, SwiftForth, or
>> > VFX, but reports a stack underflow in gforth.
>> My system doesn't report stack underflow for 1 SWAP and this triggered
>> me into investigating a bit further. 1 SWAP is actually safe for a small
>> underflow because there are a few guard cells below the stack so that
>> simple underflow doesn't cause a system crash. 1 SWAP actually works.
>> The integer swapped under the stack is actually accessible - I never
>> thought about this before.
>>
>> e.g. (assume an empty stack)
>> 1234 swap over . \ displays 1234
>> 1 2 3 4 5 depth pick . \ displays 1234
>>
>> Similarly with other stack manipulation words.
>>
>> This is also the case with SwiftForth, VFX Forth, wf32 Forth.
>> Yet another way to misuse Forth!
>>
>> This is potentially useful if you want to stash some data for re-entrant
>> code without having to maintain it near the top of the stack.
>>
>
> I consider this array-out-of-bounds usage as poor and potentially dangerous practice.
> Eg Java would throw a runtime exception.

It's exploiting system peculiarities. How dangerous depends on the user.

Stack out-of-bounds is murky. Consider a system with separate fp stack:

DX-Forth 4.45 2022-01-11
Software floating-point (separate stack)
Using FORTH.SCR

le ok
le ok
le ok
le ok
le ok
le ok
le
Error: "le" f-stack?

le ok
le ok
le ok
le ok
le ok
le ok
f. 1. ok

What's not apparent to the user is that F. itself used several stack positions
in the process of displaying 1. The 'trick' was allocating more fp stack than
what the user sees. The things we do to keep users (and ourselves) happy!

In article <ssuvtb$l2s$1@dont-email.me>, do-not-use@swldwa.uk says...
> This is potentially useful if you want to stash some data for re-entrant
> code without having to maintain it near the top of the stack.
>
> --
> Gerry
>
>

Or if you want to crash an aeroplane.

john

=========================
http://johntech.co.uk
=========================

In article <ssvc31$ssl$1@gioia.aioe.org>, dxforth@gmail.com says...
> Stack out-of-bounds is murky.
>

No.
It is unaceptable.

john

=========================
http://johntech.co.uk
=========================

dxforth schrieb am Freitag, 28. Januar 2022 um 01:06:59 UTC+1:
> On 28/01/2022 09:29, minf...@arcor.de wrote:
> > Gerry Jackson schrieb am Donnerstag, 27. Januar 2022 um 21:39:10 UTC+1:
> >> On 27/01/2022 08:48, Anton Ertl wrote:
> >> > For stack underflow, there is one generality I can state: gforth (the
> >> > debugging engine) reports almost* every stack underflow, most other
> >> > Forth systems (including gforth-fast) are less pedantic. E.g.,
> >> > starting with an empty stack,
> >> >
> >> > 1 swap .
> >> >
> >> > does not report an error on gforth-fast, iforth, lxf, SwiftForth, or
> >> > VFX, but reports a stack underflow in gforth.
> >> My system doesn't report stack underflow for 1 SWAP and this triggered
> >> me into investigating a bit further. 1 SWAP is actually safe for a small
> >> underflow because there are a few guard cells below the stack so that
> >> simple underflow doesn't cause a system crash. 1 SWAP actually works.
> >> The integer swapped under the stack is actually accessible - I never
> >> thought about this before.
> >>
> >> e.g. (assume an empty stack)
> >> 1234 swap over . \ displays 1234
> >> 1 2 3 4 5 depth pick . \ displays 1234
> >>
> >> Similarly with other stack manipulation words.
> >>
> >> This is also the case with SwiftForth, VFX Forth, wf32 Forth.
> >> Yet another way to misuse Forth!
> >>
> >> This is potentially useful if you want to stash some data for re-entrant
> >> code without having to maintain it near the top of the stack.
> >>
> >
> > I consider this array-out-of-bounds usage as poor and potentially dangerous practice.
> > Eg Java would throw a runtime exception.
> It's exploiting system peculiarities. How dangerous depends on the user.
>
> Stack out-of-bounds is murky. Consider a system with separate fp stack:
>
> DX-Forth 4.45 2022-01-11
> Software floating-point (separate stack)
> Using FORTH.SCR
>
> le ok
> le ok
> le ok
> le ok
> le ok
> le ok
> le
> Error: "le" f-stack?
>
> le ok
> le ok
> le ok
> le ok
> le ok
> le ok
> f. 1. ok
>
> What's not apparent to the user is that F. itself used several stack positions
> in the process of displaying 1. The 'trick' was allocating more fp stack than
> what the user sees. The things we do to keep users (and ourselves) happy!

Do you call THIS the Principle of Least Surprise? ;-)

Gerry Jackson <do-not-use@swldwa.uk> writes:
>The integer swapped under the stack is actually accessible - I never
>thought about this before.
>
>e.g. (assume an empty stack)
>1234 swap over . \ displays 1234
>1 2 3 4 5 depth pick . \ displays 1234
>
>Similarly with other stack manipulation words.
>
>This is also the case with SwiftForth, VFX Forth, wf32 Forth.
>Yet another way to misuse Forth!
>
>This is potentially useful if you want to stash some data for re-entrant
>code without having to maintain it near the top of the stack.

It won't work for recursive calls, therefore not for general
re-entrant code. It would have per-thread space for multi-threaded
code, but you can do the same with a user variable.

The other problem with the idea is that there is no good way to do the
stashing. You can get the value with "DEPTH PICK", but there is no
standard or at least common word for storing the value.

And if you really want to want to store at the bottom of the stack,
the (slightly) more portable approach is to store it in the bottom
element, not in the below-bottom element, e.g. (on SwiftForth):

987 1234 depth 1- -roll
1 2 3 4 5 depth 1- pick . \ prints 1234
..s \ prints 1234 987 1 2 3 4 5 <-Top

Given that the normal idiom in Forth is that words leave the stack
below their input parameters alone, storing one value in a program in
such a way should not interfere with normal code. Of course, in
general storing multiple values in this way does not work unless the
accesses to the two values follow some specific discipline; but that's
the same whether you stash in the bottom element or in the
below-bottom element. Actually, if you stash in the below-bottom
element with "PICK -ROLL", the previously stashed value becomes the
bottom element; if you stash with STICK, the previously stashed value
is overwritten.

But the major question is why you would want to stash a value there.
If you are in a word with stack effect ( a b c -- d e ), and you need
to stash a value away, why not just put it in the return stack, a
local, or the data stack at a position with at most the same depth as
a/d? That gives you true re-entrancy and more performance, and these
are probably the reason why these are the standard idioms in Forth.

- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: http://www.forth200x.org/forth200x.html
EuroForth 2021: https://euro.theforth.net/2021

On 28/01/2022 22:17, minf...@arcor.de wrote:
> dxforth schrieb am Freitag, 28. Januar 2022 um 01:06:59 UTC+1:
>> On 28/01/2022 09:29, minf...@arcor.de wrote:
>> > Gerry Jackson schrieb am Donnerstag, 27. Januar 2022 um 21:39:10 UTC+1:
>> >> On 27/01/2022 08:48, Anton Ertl wrote:
>> >> > For stack underflow, there is one generality I can state: gforth (the
>> >> > debugging engine) reports almost* every stack underflow, most other
>> >> > Forth systems (including gforth-fast) are less pedantic. E.g.,
>> >> > starting with an empty stack,
>> >> >
>> >> > 1 swap .
>> >> >
>> >> > does not report an error on gforth-fast, iforth, lxf, SwiftForth, or
>> >> > VFX, but reports a stack underflow in gforth.
>> >> My system doesn't report stack underflow for 1 SWAP and this triggered
>> >> me into investigating a bit further. 1 SWAP is actually safe for a small
>> >> underflow because there are a few guard cells below the stack so that
>> >> simple underflow doesn't cause a system crash. 1 SWAP actually works.
>> >> The integer swapped under the stack is actually accessible - I never
>> >> thought about this before.
>> >>
>> >> e.g. (assume an empty stack)
>> >> 1234 swap over . \ displays 1234
>> >> 1 2 3 4 5 depth pick . \ displays 1234
>> >>
>> >> Similarly with other stack manipulation words.
>> >>
>> >> This is also the case with SwiftForth, VFX Forth, wf32 Forth.
>> >> Yet another way to misuse Forth!
>> >>
>> >> This is potentially useful if you want to stash some data for re-entrant
>> >> code without having to maintain it near the top of the stack.
>> >>
>> >
>> > I consider this array-out-of-bounds usage as poor and potentially dangerous practice.
>> > Eg Java would throw a runtime exception.
>> It's exploiting system peculiarities. How dangerous depends on the user.
>>
>> Stack out-of-bounds is murky. Consider a system with separate fp stack:
>>
>> DX-Forth 4.45 2022-01-11
>> Software floating-point (separate stack)
>> Using FORTH.SCR
>>
>> le ok
>> le ok
>> le ok
>> le ok
>> le ok
>> le ok
>> le
>> Error: "le" f-stack?
>>
>> le ok
>> le ok
>> le ok
>> le ok
>> le ok
>> le ok
>> f. 1. ok
>>
>> What's not apparent to the user is that F. itself used several stack positions
>> in the process of displaying 1. The 'trick' was allocating more fp stack than
>> what the user sees. The things we do to keep users (and ourselves) happy!
>
> Do you call THIS the Principle of Least Surprise? ;-)

What would you call it?

On 27/01/2022 22:29, minf...@arcor.de wrote:
> Gerry Jackson schrieb am Donnerstag, 27. Januar 2022 um 21:39:10 UTC+1:
>> On 27/01/2022 08:48, Anton Ertl wrote:
>>> For stack underflow, there is one generality I can state: gforth (the
>>> debugging engine) reports almost* every stack underflow, most other
>>> Forth systems (including gforth-fast) are less pedantic. E.g.,
>>> starting with an empty stack,
>>>
>>> 1 swap .
>>>
>>> does not report an error on gforth-fast, iforth, lxf, SwiftForth, or
>>> VFX, but reports a stack underflow in gforth.
>> My system doesn't report stack underflow for 1 SWAP and this triggered
>> me into investigating a bit further. 1 SWAP is actually safe for a small
>> underflow because there are a few guard cells below the stack so that
>> simple underflow doesn't cause a system crash. 1 SWAP actually works.
>> The integer swapped under the stack is actually accessible - I never
>> thought about this before.
>>
>> e.g. (assume an empty stack)
>> 1234 swap over . \ displays 1234
>> 1 2 3 4 5 depth pick . \ displays 1234
>>
>> Similarly with other stack manipulation words.
>>
>> This is also the case with SwiftForth, VFX Forth, wf32 Forth.
>> Yet another way to misuse Forth!
>>
>> This is potentially useful if you want to stash some data for re-entrant
>> code without having to maintain it near the top of the stack.
>>
>
> I consider this array-out-of-bounds usage as poor and potentially dangerous practice.
> Eg Java would throw a runtime exception.

I don't disagree, which is why I wrote 'way to misuse Forth', also it is
non-portable. But, acting as devil's advocate, and speaking for my
system only.

From the system's point of view such an access is not an
'array-out-of-bounds' access as it is still within the memory allocated
for the stack. So it is valid for such a system to use it (by the way my
system doesn't).

From the user's point of view it does appear to be out of bounds for a
standard program because the system makes only a part of the stack
directly visible to the user. But as long as the stack underflow is not
more than a few cells it's as safe as any other stack cell.

Of course other systems that I quoted where the simple accesses do
appear to work may be corrupting something that has no visible effect in
such simple non-standard examples.

--
Gerry

On 28/01/2022 11:36, Anton Ertl wrote:
> Gerry Jackson <do-not-use@swldwa.uk> writes:
>> The integer swapped under the stack is actually accessible - I never
>> thought about this before.
>>
>> e.g. (assume an empty stack)
>> 1234 swap over . \ displays 1234
>> 1 2 3 4 5 depth pick . \ displays 1234
>>
>> Similarly with other stack manipulation words.
>>
>> This is also the case with SwiftForth, VFX Forth, wf32 Forth.
>> Yet another way to misuse Forth!
>>
>> This is potentially useful if you want to stash some data for re-entrant
>> code without having to maintain it near the top of the stack.
>
> It won't work for recursive calls,

Why not? I would envisage it as constant during recursion when DEPTH
PICK will always retrieve it whatever the level of recursion. I wasn't
thinking of writing to it repeatedly.

> therefore not for general
> re-entrant code. It would have per-thread space for multi-threaded
> code, but you can do the same with a user variable.
>
> The other problem with the idea is that there is no good way to do the
> stashing. You can get the value with "DEPTH PICK", but there is no
> standard or at least common word for storing the value.

Given that we're talking about non-standard usage saying there's no
standard way to save it is a weak argument. A non standard way to save
it is a bit messy e.g. assuming the top of stack is to go there:
: bury >r depth roll drop r> depth -roll ;

But much simpler if there only 2 or fewer items on the stack

>
> And if you really want to want to store at the bottom of the stack,
> the (slightly) more portable approach is to store it in the bottom
> element, not in the below-bottom element, e.g. (on SwiftForth):
>
> 987 1234 depth 1- -roll
> 1 2 3 4 5 depth 1- pick . \ prints 1234
> .s \ prints 1234 987 1 2 3 4 5 <-Top
>

Yes I've been aware of that for many years.

> Given that the normal idiom in Forth is that words leave the stack
> below their input parameters alone, storing one value in a program in
> such a way should not interfere with normal code. Of course, in
> general storing multiple values in this way does not work unless the
> accesses to the two values follow some specific discipline; but that's
> the same whether you stash in the bottom element or in the
> below-bottom element. Actually, if you stash in the below-bottom
> element with "PICK -ROLL", the previously stashed value becomes the
> bottom element;

Yes that's obvious, see BURY above. Yes it would have to be used with
care, but that's true of normal stack operations anyway.

> if you stash with STICK, the previously stashed value
> is overwritten.
>
> But the major question is why you would want to stash a value there.

I don't want to, it was just your statement about stack underflow on
different systems that triggered me into wondering how systems behaved
and just pointing out some quirky behaviour.

> If you are in a word with stack effect ( a b c -- d e ), and you need
> to stash a value away, why not just put it in the return stack, a
> local, or the data stack at a position with at most the same depth as
> a/d? That gives you true re-entrancy and more performance, and these
> are probably the reason why these are the standard idioms in Forth.

When interpreting using the R stack and locals are non-standard.

--
Gerry

On 29/01/2022 06:55, Gerry Jackson wrote:
> ...
> Of course other systems that I quoted where the simple accesses do
> appear to work may be corrupting something that has no visible effect in
> such simple non-standard examples.

Ideally a system would be designed such that even if a user makes a
simple stack error it won't trash the system. Fine if the system/OS
can sense under/overflow before it happens but least harm done if it
can't.

dxforth schrieb am Samstag, 29. Januar 2022 um 01:05:11 UTC+1:
> On 29/01/2022 06:55, Gerry Jackson wrote:
> > ...
> > Of course other systems that I quoted where the simple accesses do
> > appear to work may be corrupting something that has no visible effect in
> > such simple non-standard examples.
> Ideally a system would be designed such that even if a user makes a
> simple stack error it won't trash the system. Fine if the system/OS
> can sense under/overflow before it happens but least harm done if it
> can't.

Ideally user errors like stack underflow should throw an exception _without_
crashing the system.

Perhaps system words should use their own stacks/registers without
affecting user stacks at all ...

It is a bit diametricical to the prevailing Forth "philosophy" of sacrificing
safety for speed.

On Saturday, January 29, 2022 at 9:23:13 AM UTC+1, minf...@arcor.de wrote:
> dxforth schrieb am Samstag, 29. Januar 2022 um 01:05:11 UTC+1:
> > On 29/01/2022 06:55, Gerry Jackson wrote:
> > > ...
> > > Of course other systems that I quoted where the simple accesses do
> > > appear to work may be corrupting something that has no visible effect in
> > > such simple non-standard examples.
> > Ideally a system would be designed such that even if a user makes a
> > simple stack error it won't trash the system. Fine if the system/OS
> > can sense under/overflow before it happens but least harm done if it
> > can't.
> Ideally user errors like stack underflow should throw an exception _without_
> crashing the system.
>
> Perhaps system words should use their own stacks/registers without
> affecting user stacks at all ...
>
> It is a bit diametricical to the prevailing Forth "philosophy" of sacrificing
> safety for speed.

I seldomly see stack errors in code once it is debugged. There might be
unchecked code paths for situations that I initially thought extremely
unlikely.

What I notice in my own code is lots of errors with illegal memory access.
The reason it appears so frequenly is that I know that this type of error
is almost perfectly caught by the system and is very easy to correct,
so I just run the word without carefully desk-checking that portion of
the code.

The same happens when I program in C, I tend to run code with
complicated macros and library calls without carefully looking
up the documentation and have the debugger disassemble or
untangle the confusing parts :--)

-marcel