fp-stack.html

<title>Separate FP Stack</title>

<h3>Separate FP Stack</h3>

[ <a href="rfds.html">RfDs/CfVs</a> | <a href="proposals.html">Other proposals</a> ]

<h4>Poll standings</h4>

See <a href="#voting">below</a> for voting instructions.

The results will be shown here in late August 2006.

<h5>Systems</h5>

<pre>
[ ] conforms to ANS Forth.
 Mops/PowerMops (Mike Hore)
 ForthCAD (Charles Melice)
 iForth (Marcel Hendrix)
 bigForth (Bernd Paysan)
 Gforth (Anton Ertl)
 VFX Forth for Windows/DOS/Linux (Stephen Pelc)
 MPE Forth cross compilers
 MacForth/Power MacForth/Carbon MacForth (Ward McFarland)
 TCBForth (Tessa Celine Bonting)
 PFE (Guido Draheim)
[ ] already implements the proposal in full since release [ ]:
 PowerMops 3
 iForth 1
 bigForth 1.0
 Gforth 0.1
 VFX Forth for Windows/DOS/Linux 3.0
 MacForth/Power MacForth/Carbon MacForth since at least 10 years
 PFE 0.7 (first release)
 4th v3.5c, release 3 (Hans Bezemer)
[ ] implements the proposal in full in a development version:
 TCBForth
[ ] will implement the proposal in full in release [ ].
 MPE Forth cross compilers 7.0
[ ] will implement the proposal in full in some future release.
 ForthCAD
 kForth (Krishna Myneni)
There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full:
</pre>

<h5>Programmers</h5>

<pre>
[ ] I have used (parts of) this proposal in my programs:
 David N. Williams
 Charles Melice
 Julian V. Noble
 Bernd Paysan
 Anton Ertl
 Stephen Pelc
 Hans Bezemer
[ ] I would use (parts of) this proposal in my programs if the systems
    I am interested in implemented it:
 David N. Williams
 Charles Melice
 Stephen Pelc
 Tessa Celine Bonting
[ ] I would use (parts of) this proposal in my programs if this
    proposal was in the Forth standard:
 David N. Williams
 Stephen Pelc
[ ] I would not use (parts of) this proposal in my programs.
 Hans Bezemer (does not use FP)
</pre>

<h5>Informal results</h5>

Charles Melice has developed a program that allows running his
unified-stack 1-cell-per-fp legacy code on a separate-stack system.

<p>Julian V. Noble would never use a system with a unified stack.

<p>BigForth: The 68k software FP implementation of bigFORTH containes
an optional mode where the stack is unified. The x86 version uses the
native stack of the x87 FPU, and didn't offer this unified stack
option.

<p>PFE provides two floating-ext implementations, one with a seperate
floating-stack and one with an integrated floating-stack. Both conform
to ANS Forth - loading "fpnostack-ext" will also provide a
"floating-ext" environme nt entry while the default "floating-ext"
environment query will yield a configurat ion with a separate
fp-stack.

<p>Krishna Myneni (kForth) writes: In the interest of code portability
among Forth 200x-like systems, our plan is to make use of the
separated fp stack as the default mode in a future release of
kForth. We will maintain an option for operating kForth in a unified
stack mode, to support legacy code.

<h4>Change History</h4>

<dl>
<dt>2006-07-04 <dd>No normative changes.  Updated Section Experience
with ForthCAD material.  Added Testst.

<dt>2006-06-27 <dd>No normative changes.  Updated Section Experience
with material from feedback on the 1st RfD.  Added Section Remarks.

</dl>


<h4>Problem</h4>

Writing floating-point code such that it can run on a unified stack is
such a pain that most programmers don't do it.


<h4>Proposal</h4>

The floating-point stack is separate from the data stack.


<h4>Typical Use</h4>

<pre>
\ from &lt;126r7o1srr8aof0@news.supernews.com&gt;
: square ( f - f')  fdup f* ;
: pow ( n) ( f - f')
   ?dup 0= if  fdrop 1e0 exit  then
   dup 1 = if  drop exit  then
   2 /mod  fdup square recurse  fswap recurse f* ;
</pre>

<h4>Remarks</h4>

<h5>Unified stacks with a specified size for FP values</h5>

While many agreed with the "pain" assessment above, several comments
pointed out that the unified stack is not as big a pain if the
programmer programs for a specific on-stack size of FP values (e.g.,
double-cells), if that size is not larger than double-cells.

<p>However, such a dependency on a specific size of FP values reduces the
portability even to other systems with a unified stack (and maybe even
to other platforms for the same system) as well as eliminating the
portability to systems with a separate FP stack.

<h5>Temporary storage</h5>

C. G. Montgomery proposed adding words for transferring values between
the FP stack and the data stack for temporary storage
&lt;e5vtr3$qv3$1@pyrite.mv.net&gt;.  The return stack seems to be a
better place for temporary storage, though.  Marcel Hendrix would
prefer to see FP locals instead &lt;03191418173561@frunobulax.edu&gt;.
Since there is a promise for an upcoming proposal for FP locals, I
will not propose any such words in this proposal.

<!--

<h5>Compatibility</h5>

Existing ANS Forth programs continue to work (they support both
separate and unified stacks).

<p>Existing ANS Forth programs with an environmental dependency on a
separate stack continue to work (of course).

<p>Existing ANS Forth programs with an environmental dependency on a
unified stack and a specific size for FP stack items will break, but
they also break when moved to a system with a unified stack with a
different FP stack size.

<p>ANS Forth programs with an environmental dependency on a unified
stack without a dependency on the FP stack item size cannot exist.


<h5>Standardisation</h5>

How should this proposal be integrated into the Forth200x standard?
As extension (i.e. optional) or as requirement.  That's up to the
standardisation committee to decide, but here are some thoughts on the
effects:

<p>This is an option already, so the only effect that making it an
option in the standard would have is that an extension query
<code>X:fp-stack</code> might be a stronger hint to the system that
the programmer wants a separate FP stack than the environmental query
<code>FLOATING-STACK</code>.

<p>All other RfDs until now have been optional, so if this was a
requirement, this would be a first.
-->

<h4>Experience</h4>

Most ANS Forth systems that I know implement a separate floating-point
stack.  MPE's embedded systems use a unified stack (their desktop
system use separated stacks).  Kforth implements a subset of ANS Forth
subset and has a unified FP stack.  PFE implements ANS Forth and has
an optional module for a unified stack (it also supports a separate FP
stack).  ForthCAD (ANS Forth status unknown), COLDFORTH (ANS
compliant) and uCFORTH (ANS compliant) use a unified stack.  ForthCAD
originally used this to make the implementation of the C call
interface simpler on the IA-32 architecture, and sticks with it
because there is too much code that relies on this.

<p>All (near-)ANS Forth programs dealing with FP numbers that I know
except code written specifically for kforth just assume a separate
floating-point stack, including the Forth Scientific Library.


<h4>Implementation and Tests</h4>

<ul>

<li><a
href="reference-implementations/fp-stack.fs">Implementation</a>; needs
(system-specific) text-interpreter floating-point input.

<li> <a href="tests/fp-stack.fs">Tests</a>

</ul>

<!--
<h4>Comments</h4>
-->

<h4><a name="voting">Voting instructions</a></h4>

Fill out the appropriate ballot(s) below and mail it/them to me
&lt;anton@mips.complang.tuwien.ac.at&gt;.  Your vote will be published
(including your name (without email address) and/or the name of your
system) here.  You can vote (or change your vote) at any time by
mailing to me, and the results will be published here.

<p>Note that you can be both a system implementor and a programmer, so
you can submit both kinds of ballots.

<h4>Ballot for systems</h4>

If you maintain several systems, please mention the systems separately
in the ballot.  Insert the system name or version between the
brackets.  Multiple hits for the same system are possible (if they do
not conflict).

<pre>
[ ] conforms to ANS Forth.
[ ] already implements the proposal in full since release [ ].
[ ] implements the proposal in full in a development version.
[ ] will implement the proposal in full in release [ ].
[ ] will implement the proposal in full in some future release.
There are no plans to implement the proposal in full in [ ].
[ ] will never implement the proposal in full.
</pre>

If you want to provide information on partial implementation, please
do so informally, and I will aggregate this information in some way.


<h4>Ballot for programmers</h4>

Just mark the statements that are correct for you (e.g., by putting an
"x" between the brackets).  If some statements are true for some of
your programs, but not others, please mark the statements for the
dominating class of programs you write.

<pre>
[ ] I have used (parts of) this proposal in my programs.
[ ] I would use (parts of) this proposal in my programs if the systems
    I am interested in implemented it.
[ ] I would use (parts of) this proposal in my programs if this
    proposal was in the Forth standard.
[ ] I would not use (parts of) this proposal in my programs.
</pre>

If you feel that there is closely related functionality missing from
the proposal (especially if you have used that in your programs), make
an informal comment, and I will collect these, too.  Note that the
best time to voice such issues is the RfD stage.

<hr><a href="http://www.complang.tuwien.ac.at/anton/">Anton Ertl</a>