Sujet : Re: Juggling system-compilation items
De : albert (at) *nospam* spenarnc.xs4all.nl
Groupes : comp.lang.forthDate : 12. Aug 2024, 10:45:39
Autres entêtes
Organisation : KPN B.V.
Message-ID : <nnd$37164d96$3acc3df6@43c3aecde4ca6b05>
References : 1 2
User-Agent : trn 4.0-test77 (Sep 1, 2010)
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.
>
Therefore I developed my system (for desktop systems only) with a
separate control flow stack. It doesn't stop checking for unbalanced
stack errors. As it is only used when compiling speed isn't important it
can be a linked list implementation discarded at runtime. It allows data
to be passed into or out of colon definitions or other control
structures without considering the control stack unless you are trying
to write portable software.
>
So in your definition above the use of DEPTH, N>R etc is unnecessary as
DEPTH >R : DEPTH R> -
returns 0 for my system. CONST works.
>
--
Gerry
>
-- 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 thehide of the bear until you shot it. Better one bird in the hand than ten inthe air. First gain is a cat purring. - the Wise from Antrim -