Andreas Kochenburger nospam.com> wrote:

The 8087. When that chip was designed, it was intended to have an
interrupt that pushed to registers on overflow, giving unlimited
floating-point stack depth, but the interrupt didn't work. So, users
of the 8087 are limited to 8 items. Forth's limit is six: the extra
two are for system overhead.

Andrew.

Krishna Myneni wrote:

ANS Forth allows implementations with a deep fp stack, and allows code
that requires a deep fp stack, so neither of those would change.

The only substantial change would therefore be to rule out
implementations with short fp stacks.

Of course, supporting small RAM microcontrollers is the most plausible
argument that has been advanced for indefinite maintenance of the
mixed-stack standard, and so ruling out short fp stacks would excise
that argument. But I don't see that as an argument in favor of any such
change.

Bruce McFarling wrote:

Krishna Myneni wrote:

But why change the one that is done the right way around?

For a seperate floating point stack, you have to provide a stack at
least six deep. For the data and return stack, you could provide four
each and it would still comply with the standard.

Out of curiosity:

12.3.3 Floating-point stack
...
A program that depends on the floating-point stack being larger than
six items has an environmental dependency.

How come that this restriction came into the standard?
Many recursive algorithms require more depth.

Andreas

On Thu, 11 Jan 2007 12:31:53 -0000, Andrew Haley
wrote:

In other words: Intel's shortcomings became somehow the Forth
standard?

Andreas

Andreas Kochenburger nospam.com> writes:

My impression (from what I read about the standardisation effort) is
that FP was quite well prepared, building on a quasi-standard from the
"Forth Vendor's group" or somesuch.

But you can rejoice. I expect that, with AMD64 taking over from
IA-32, the 8087 stack will become less important than it has been
(with both language and hardware implementations favouring the XMM
registers), there will be more and more Forth systems offering big FP
stacks, and if there are enough people making use of that, maybe this
limit will be removed in Forth 201x.

OTOH, at least you are guaranteed 6 items for the FP stack. There is
no such guarantee for the data stack or the return stack, so a
(low-quality) system could already stop working if you need more than,
say, 4, stack items.

Krishna Myneni wrote:

The current standard does not *force* you to have a small FP stack. It also
does not force you to write programs which only use a small stack, unless
e.g. you use bigFORTH. On the other hand, there's *no* guarantee how big
the data stack or return stack is (or at least I couldn't find it). So any
program has an environmental dependency on whatever data and return stack
depth it uses, while there are programs that have no environmental
dependency on FP stack depth, when they fit into the guaranteed 6 items.

Bernd Paysan wrote:

Hi Bernd,

Krishna Myneni wrote:

Gforth EC for the R8C was a project that started a year ago. Small embedded
processors are still there today, and they are useful, because they are
dirt cheap.

I agree that a deep FP stack can be useful from time to time, and that in
general, a PC Forth should not impose arbitrary limitations unless there's
a good reason (in bigFORTH's case it's the tradeoff between performance and
ease of implementation). I'm not sure if your examples are good, e.g.
copying a row of a large matrix on the stack and then copying it back to
another matrix seems to be suboptimal compared to copying straight without
the stack in between. Recursion is more in the line of being useful.