Return stack manipulation

[Stephen Pelc]

On 6 Jun 2022 at 18:16:17 CEST, "dxforth" <dxf...@gmail.com> wrote:
I'm puzzled by the claim an optimizing compiler wouldn't know how to
handle a colon definition with UNNEST or ABANDON in it. When I write a
discrete definition I expect the compiler to respect that and optimize
only when safe to do so. The presence of those words should signal
don't inline this definition.

The whole return stack manipulation issue is more complex that you give
it credit for. There are three scenarios:

1) classical Forth - return address is on return stack unmodified
This applies for most x86/x64 Forths. It's possible to track the use of
> R and R> and you can predict how many levels of return address
are involved. However, I have not been able to convince myself
that this can be done completely accurately.

2) Modified return address - e.g. ARM Cortex M
In these systems there's a single-cell return address where you expect
it, but it has some modifications, e.g. bit 0 is always 1.

3) Return address is not a single cell - e.g. DSPIC

There were papers about this topic by Michael Gassanenko, who
proposed a return stack manipulation wordset for the purpose. It
was the closest approach to sanity given the problems. Also, I can
guess what UNNEST does, but ABANDON? - Give me a break. See
http://www.euroforth.org/ef98/gassanenko98b.pdf

Stephen
--
--
Stephen Pelc, ste...@vfxforth.com
MicroProcessor Engineering, Ltd. - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, +44 (0)78 0390 3612, +34 649 662 974
http://www.mpeforth.com - free VFX Forth downloads

[none albert]

In article <t7nta9$nc4$1...@dont-email.me>,

Stephen Pelc <ste...@vfxforth.com> wrote:
>On 6 Jun 2022 at 18:16:17 CEST, "dxforth" <dxf...@gmail.com> wrote:
>I'm puzzled by the claim an optimizing compiler wouldn't know how to
>handle a colon definition with UNNEST or ABANDON in it. When I write a
>discrete definition I expect the compiler to respect that and optimize
>only when safe to do so. The presence of those words should signal
>don't inline this definition.

Assuming the compiler supplies the word UNNEST, then the optimiser
that goes with the compiler is reasonable expected to handle that.
Even the warning "the optimiser can't handle words that uses UNNEST"
is perfectly reasonable.
What is not reasonable to assume that there is a portable
definition of UNNEST.

I'm working on an optimiser.
EXIT'S UNLOOP's R>'s are handled fine, as used per the standard.
If you're Using RDROP as an UNNEST , the optimiser doesn't
work plain and simple.

>Stephen
--
"in our communism country Viet Nam, people are forced to be
alive and in the western country like US, people are free to
die from Covid 19 lol" duc ha
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[dxforth]

On 8/06/2022 02:10, Stephen Pelc wrote:
> On 6 Jun 2022 at 18:16:17 CEST, "dxforth" <dxf...@gmail.com> wrote:
> I'm puzzled by the claim an optimizing compiler wouldn't know how to
> handle a colon definition with UNNEST or ABANDON in it. When I write a
> discrete definition I expect the compiler to respect that and optimize
> only when safe to do so. The presence of those words should signal
> don't inline this definition.
>
> The whole return stack manipulation issue is more complex that you give
> it credit for. There are three scenarios:
>
> 1) classical Forth - return address is on return stack unmodified
> This applies for most x86/x64 Forths. It's possible to track the use of
>> R and R> and you can predict how many levels of return address
> are involved. However, I have not been able to convince myself
> that this can be done completely accurately.
>
> 2) Modified return address - e.g. ARM Cortex M
> In these systems there's a single-cell return address where you expect
> it, but it has some modifications, e.g. bit 0 is always 1.
>
> 3) Return address is not a single cell - e.g. DSPIC
>
> There were papers about this topic by Michael Gassanenko, who
> proposed a return stack manipulation wordset for the purpose. It
> was the closest approach to sanity given the problems. Also, I can
> guess what UNNEST does, but ABANDON? - Give me a break. See
> http://www.euroforth.org/ef98/gassanenko98b.pdf

MLG is an academic. Solving everyone's problem is what they do. What
begins as an itch begets scratching which develops into a rash before
long they're applying buckets of ointment and offering it to the world
as a solution.

Perhaps it's just as well Moore hadn't seen MLG's paper or been presented
with one or two architectures where return stack manipulation wasn't
trivial, then perhaps he too might have been persuaded to just accept
CATCH/THROW.

[dxforth]

On 8/06/2022 03:00, albert wrote:
> In article <t7nta9$nc4$1...@dont-email.me>,
> Stephen Pelc <ste...@vfxforth.com> wrote:
>>On 6 Jun 2022 at 18:16:17 CEST, "dxforth" <dxf...@gmail.com> wrote:
>>I'm puzzled by the claim an optimizing compiler wouldn't know how to
>>handle a colon definition with UNNEST or ABANDON in it. When I write a
>>discrete definition I expect the compiler to respect that and optimize
>>only when safe to do so. The presence of those words should signal
>>don't inline this definition.
>
> Assuming the compiler supplies the word UNNEST, then the optimiser
> that goes with the compiler is reasonable expected to handle that.
> Even the warning "the optimiser can't handle words that uses UNNEST"
> is perfectly reasonable.
> What is not reasonable to assume that there is a portable
> definition of UNNEST.

Indeed - even then how hard can it be to pop one nesting level (wherever
it happens to reside). Neither my UNNEST nor Ulrich Hoffmann's 1994
equivalent ABANDON called for "return stack manipulation". It was the
same with floats on the data stack. Academics were saying it would
require a slew of new stack operators (clumsier than variables) when
nobody had proposed any such thing. Anti-vaxxers could learn a thing
or two from forthers, so adept are we at disinformation.

[anti...@math.uni.wroc.pl]

Stephen Pelc <ste...@vfxforth.com> wrote:
> On 6 Jun 2022 at 18:16:17 CEST, "dxforth" <dxf...@gmail.com> wrote:
> I'm puzzled by the claim an optimizing compiler wouldn't know how to
> handle a colon definition with UNNEST or ABANDON in it. When I write a
> discrete definition I expect the compiler to respect that and optimize
> only when safe to do so. The presence of those words should signal
> don't inline this definition.
>
> The whole return stack manipulation issue is more complex that you give
> it credit for. There are three scenarios:
>
> 1) classical Forth - return address is on return stack unmodified
> This applies for most x86/x64 Forths. It's possible to track the use of
> > R and R> and you can predict how many levels of return address
> are involved. However, I have not been able to convince myself
> that this can be done completely accurately.
>
> 2) Modified return address - e.g. ARM Cortex M
> In these systems there's a single-cell return address where you expect
> it, but it has some modifications, e.g. bit 0 is always 1.
>
> 3) Return address is not a single cell - e.g. DSPIC
>

Hmm, IIUC a lot of processors store return address in register.
In leaf functions there is no need to store this address on
the stack.

I did not look at fine print is Forth standard, but there
is some wording limiting what can be done portably with
return stack. I would guess is that implementation where
retrun address is on machine stack, but machine stack
is different than Forth return stack is legal.

In similar spirit, I would think that adding extra padding
(say to align the stack) is legal. If my guesses are
correct, then portable Forth program can not expect predictable
results from attempts to change return address on return
stack.

--
Waldek Hebisch

[dxforth]

On 11/06/2022 07:08, anti...@math.uni.wroc.pl wrote:
> Stephen Pelc <ste...@vfxforth.com> wrote:
>> On 6 Jun 2022 at 18:16:17 CEST, "dxforth" <dxf...@gmail.com> wrote:

[snipped]

>> The whole return stack manipulation issue is more complex that you give
>> it credit for. There are three scenarios:
>>
>> 1) classical Forth - return address is on return stack unmodified
>> This applies for most x86/x64 Forths. It's possible to track the use of
>> > R and R> and you can predict how many levels of return address
>> are involved. However, I have not been able to convince myself
>> that this can be done completely accurately.
>>
>> 2) Modified return address - e.g. ARM Cortex M
>> In these systems there's a single-cell return address where you expect
>> it, but it has some modifications, e.g. bit 0 is always 1.
>>
>> 3) Return address is not a single cell - e.g. DSPIC
>>
>
> Hmm, IIUC a lot of processors store return address in register.
> In leaf functions there is no need to store this address on
> the stack.
>
> I did not look at fine print is Forth standard, but there
> is some wording limiting what can be done portably with
> return stack. I would guess is that implementation where
> retrun address is on machine stack, but machine stack
> is different than Forth return stack is legal.
>
> In similar spirit, I would think that adding extra padding
> (say to align the stack) is legal. If my guesses are
> correct, then portable Forth program can not expect predictable
> results from attempts to change return address on return
> stack.

I would think UNNEST is do-able. Locals would be restricted in the
same way ANS restricted return stack access when DO LOOP is in play
i.e. no guarantee it will work. Back in the day when Brad Rodriguez
was fired up over ANS he was advocating for 'general' access:

Category 10, Topic 30
Message 230 Sat Jul 11, 1992
B.RODRIGUEZ2 [Brad] at 12:49 EDT

David Hasan: You have neatly summed up the problem with UNNEST. As
I pointed out previously, this word would solve ONE problem I have
(entitlement to R> DROP), but not the GENERAL problem (entitlement
to return stack information).

Can't say what his views are today. For myself I can justify UNNEST -
it's a synonym of RDROP and I have used it to good effect. The
'general problem' of others I don't need to worry about.

[none albert]

You are aware that the actually return stack can be completely hidden
by the implementation?
There is nothing in the standard that the return stack is actually
used to store return addresses.
It is completely legal to have a separate stack to implement
>R R> R@ , with the advantage that it doesn't interfere with
locals, do-loop's etc.

Groetjes Albert

[Anton Ertl]

anti...@math.uni.wroc.pl writes:
>I did not look at fine print is Forth standard, but there
>is some wording limiting what can be done portably with
>return stack.

In recent threads, it has been discussed what the standard specifies
about the topic and where.

>I would guess is that implementation where
>retrun address is on machine stack, but machine stack
>is different than Forth return stack is legal.

Your guess is correct. A standard program cannot even detect whether
a return address exists, and certainly not where it resides if it
exists.

>If my guesses are
>correct, then portable Forth program can not expect predictable
>results from attempts to change return address on return
>stack.

That's a wrong-headed way to reason about the requirements of the
standard. In general the standard gives guarantees about the
behaviour of standard systems to standard programs. A standard system
has to implement these guarantees, and a standard program can rely on
them. You don't have to reason about hypothetical system
implementations to understand what is guaranteed, and such reasoning
has just led to circular (and wrong wrt the standard) reasoning in the
past.

In the present case, the standard gives essentially no guarantees
about a nest-sys (a return address). So a standard program cannot
rely on it, and a standard system can implement it pretty much in any
way it wants, including not having a return address as a data item at
all.

- 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: https://forth-standard.org/
EuroForth 2022: http://www.euroforth.org/ef22/cfp.html

[dxforth]

Sure. I had no interest in maintaining another stack. Stacks for
data >R...R> and maybe floats was plenty for ?STACK to worry about.