Re: Juggling system-compilation items

In article <v9gc9i$1nqu$1@dont-email.me>,
Gerry Jackson  <do-not-use@swldwa.uk> wrote:

On 12/08/2024 10:45, albert@spenarnc.xs4all.nl wrote:

In article<v9bdpm$2sbsi$1@dont-email.me>,
Gerry Jackson<do-not-use@swldwa.uk>  wrote:

ISTM that using the data stack to hold the control stack is an
anachronism that was used in early Forth systems because of the limited
amount of memory available. I also think that the system should not get
in the way of user programs as putting control stack data on the data
stack certainly does.

It alleviates restriction. Marcel Hendrix hated the restrictions of
R> >R and added the socalled "system stack" S> >S that can be used
over definitions. The disadvantage is of course that there are more
regions of memory that you have to keep track of.
I think that added complexity is a more important consideration as
memory usage. The more stacks you have and the more stack items
you keep in registers, the more difficult e.g. task switching becomes.

>
As use of a control stack is during compilation, speed is not too
important so why would register(s) be used for it?

The control stack pointer can be a user variable, so the switching
is automatic. 1) So you are right that it doesn't impose extra
restrictions for task switching.
Probably I was rationalizing that I hate making things more complicated.
Having a separate control flow stack is a complication in itself,
but it makes other things simpler.
I have the example of restricting STATE to [ ] and INTERPRET.
Marcel Hendrix has the example of passing data to a definition.
There are probably more.

1) By swapping the user pointer, all user variables are switched.

>
--
Gerry
>

Groetjes Albert
--
Don't praise the day before the evening. One swallow doesn't make spring.
You must not say "hey" before you have crossed the bridge. Don't sell the
hide of the bear until you shot it. Better one bird in the hand than ten in
the air. First gain is a cat purring.            - the Wise from Antrim -