Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Floating Point stack
Message-ID: <9008271934.AA00290@ucbvax.Berkeley.EDU>
Date: 27 Aug 90 18:46:24 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 37

> This proposal [making a floating point stack optional] seems to
> guarantee that anyone wishing to write a "Standard" application
> using floating-point will have to write everything twice.  Then,
> of course, at the beginning of your standard program you can test
> the environment and decide which copy of the application to run.
> (I invite counter-examples.)

That is what I used to think too, until I figured out the "trick".

It turns out that the real problem is with "mixed stack" operations,
where you need to simultaneously deal with data stack and floating
point stack values.  If the floating point data is kept on the data
stack, then can you access integer data underneath it?

The solution turns out to be remarkably simple:

Suppose that we have a function FSTKCELLS

	FSTKCELLS  ( n -- ncells )
		ncells is the number of data stack items occupied
		by a n floating point numbers.

If there is a separate floating point stack, FSTKCELLS would be DROP 0.
Otherwise, it might be NOOP or 2* or 4* or whatever is correct, considering
the relative sizes of integers and floating point numbers.

Given this function, mixed stack operations can be portably expressed as
a (usually trivial) calculation involving FSTKCELLS and PICK .

Of course, this is more cumbersome than doing nothing at all, but in
an absolute sense, it is reasonably simple, effective, and less trouble
than maintaining 2 versions of the code.

Fortunately, mixed-stack operations turn out to be relatively infrequent,
and can often be avoided altogether by judicious use of variables.

Mitch