From: cbbrowne@csi.uottawa.ca (Christopher Browne)
Subject: Multiple stacks (was Re: Floating Point)
Organization: Dept. of Computer Science, University of Ottawa
Date: Tue, 6 Oct 92 19:28:31 GMT

In article <4098.UUL1.3#5129@willett.pgh.pa.us> you write:
>+It's been very useful to have two stacks, primarily intended to store
>+return addresses and function parameters, respectively.
>
>+The stacks have since been used (abused?) to store a whole variety of
>+other sorts of information; from loop counters/looping addresses to
>+some (occasionally weird) varieties of local variables.
... stuff elided
>+This made a lot of sense to me; many of the stack contortions of which
  "This" refering to the idea of maybe having >2 stacks
>+Forth programs become guilty come as a result of trying to use the two
>+"standard" stacks to do things other than the straightforward
>+Return/Parameter passing for which they are PRIMARILY intended.

>As I see it then, the question becomes:
>    Does the same kind of separation into "other stacks" for "other things"
>    yield enough benefit to make it worth while?
>
>I think the answer to that question is _not_ automatically "NO".
>
>One problem with having N stacks is that you then need N wordsets, one each
>for manipulating each of the N stacks, or you need a generic set of words
>that can operate on "the current/default" stack, plus words to allow
>selection of/movement to/conversion from one stack to another.  That is the
>general case.  Consider the specific instances of control-flow and local
>variables.  Loops, cases/cascades, etc. already have their own very limited
>wordsets (not necessarily a separate "vocabulary) for what they do.  Perhaps
>I am missing something obvious, but having a RETURN/CASE/CONTROLFLOW stack
>does not seem to me to require any NEW words to be added to Forth.  We
>already have I J K  DO LOOP   umpty-variants of CASE ... ENDCASE etc.

The "problem" of having additional wordsets doesn't HAVE to be a big
problem:

(a) For the already known "special words", there may be little
EXTERNAL need to do any inter-stack operations.

For instance, the parameters that would go on the DO LOOP stack would
be PRIMARILY manipulated using the infamous words DO, LOOP, I, J, K,
and so forth.  The "inter-stack" manipulations would be internal to
those particular words.  DO would eat values from the parameter stack;
I, J, and K would put the loop counter onto the parameter stack, and
so forth.

In fact, the main reason why current Forth programs might break if we
added a DO-LOOP stack would be that the program requires "Carnal
knowledge" of the return stack.  Seeing as how the data isn't actually
ON the return stack, the program would break.

This sort of scheme is probably quite friendly to "normal" code.  (I
await the flames from people that regularly write code that fools
around with the DO LOOP parameters.  I have a pretty good reply for
them if they do complain...  My water bucket is ready & waiting!)

(b) Then we have the more "generic" extra stacks.  The "user-defined"
stacks, for instance.

I noted a small word set (Stack:, push, pop) which could be used to
create a stack, transfer data from the parameter stack to the
"generic" stack, and vice versa.

It's TRULY a trivial exercise to make this set of words that deals
with single cells; and you can add as little or as much error checking
as you like (i.e. - Ensuring you neither overflow nor underflow the
stack).

Doing a stack for a more complex "datatype" is going to be somewhat
more difficult; but since defining a stack and its operators really
only takes about 3 or 4 lines of code, additional stacks would be easy
to hack up when needed.

I haven't mentioned machine architectures or optimization thus far;
I've been sort of assuming stack definitions that are written in
Forth.  This is going to be quite a bit slower than native code in
most cases; a more professional implementation would want to optimize
the life out of these.

On machines that are set up so as to make 2 stacks "really
convenient", my proposal WOULD slow things up.  This is unfortunate.
However, it's not desirable to prevent improvement just because
there's a few machines on which a certain representation is
suboptimal.  This isn't a DPANS proposal yet, of course!

On the other hand, there's machines out there that have lotsa
registers that often have nothing to do.  They'll win big here!

And this might lead us towards the NEXT generation of stack-based
machines; computers that have a whole RAFT of stack registers!
-- 
Christopher Browne
cbbrowne@csi.uottawa.ca
University of Ottawa
Master of System Science Program
-- 
Christopher Browne
cbbrowne@csi.uottawa.ca
University of Ottawa
Master of System Science Program
Newsgroups: comp.lang.forth