I note that Forth has traditionally had 2 stacks - data and return.

Then came the float stack.

Then, there has been further separation with a locals stack, and even an
'object' stack for forths with OO capability.

What do people think about this separation of stacks? Does it clutter the
thinking to separate out locals and objects into their own stacks, or is
it more of a help?

DavidM wrote:

In the implementations I'm familiar with, locals are implemented on the
Return Stack, and objects do not have a separate stack. I know some
people have experimented with separate loop stacks and other things, but
IMO they don't offer sufficient advantages to justify the added code
complexity.

A separate float stack solves two problems: dealing with the cumbersome
additional size of IEEE fp numbers, and enabling use of hardware fp
stacks, both very worthwhile objectives.

Elizabeth D Rather forth.com> writes Re: separate stacks

[..]

For simple implementations it doesn't matter, but locals on a separate
stack are easier to optimize; e.g.

iForth version 3.0.15, generated 22:47:30, July 28, 2008.
x86 binary, native floating-point, double precision.
Copyright 1996 - 2008 Marcel Hendrix.

Elizabeth D Rather forth.com> wrote:

Fist was the program stack which instructions were poped from one by
one, then a data stack seemed a useful idea, then return addresses
were clogging the data stack, and so processors implemented subrotine
calls, and the return stack arrived, the data stack got lost a while
in the expansion of the register file, but came back with java. Then a
split float stack came for the number crunchers, and an object stack
with stacks on. IIRC.

jacko wrote:

I'm not sure what's your frame of reference here. Are you talking about
the history of computing in general, or Forth? I'm not sure I've ever
encountered a "program stack", and float stacks precede Java, I think.

Cheers,
Elizabeth

On 2008-08-02, Andrew Haley wrote:

Elizabeth D Rather forth.com> wrote:

I just stopped to wonder, how much extra complexity would it take to
implement DO loops on the return stack like locals?

People talk like locals have hardly any runtime costs. If you could put
do loop parameters at the bottom of the word's return stack usage, with
the locals, they'd be better because the top of the return stack would
be free. I see no downside at all unless there's a performance penalty.

On Sat, 02 Aug 2008 17:52:01 -0400, Jonah Thomas wrote:

IMHO it's not very complex at all. I've done it in aumForth.

What I do is keep a compile-time variable which measures the total number
of data elements in the return stack. So then, it's possible to have a
break or exit anywhere inside any control structures, and the compiler
will know out how much data is on the return stack and generate code to
'pop n data cells' from the return stack prior to breaking.

In fact, my 'unloop' word is a no-op because it's unnecessary, and I just
have it there for ANS compatibility.

The question of whether locals have significant runtime costs is
determined by the size of the word def in which they occur, and/or the
cost of the stack-juggling which would be needed to perform the same task
without locals.

According to DavidM nowhere.com>:

Separating stacks is dipping one's foot into the cold waters of
static typing. That's not necessarily bad, but it is somewhat
unforthish.