Separate FP Stack

[ RfDs/CfVs | Other proposals ]

Poll standings

See below for voting instructions. The results will be shown here in late August 2006.
Systems
[ ] 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:
Programmers
[ ] 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)
Informal results
Charles Melice has developed a program that allows running his unified-stack 1-cell-per-fp legacy code on a separate-stack system.

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

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.

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.

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.

Change History

2006-07-04
No normative changes. Updated Section Experience with ForthCAD material. Added Testst.
2006-06-27
No normative changes. Updated Section Experience with material from feedback on the 1st RfD. Added Section Remarks.

Problem

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

Proposal

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

Typical Use

\ from <126r7o1srr8aof0@news.supernews.com>
: 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* ;

Remarks

Unified stacks with a specified size for FP values
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.

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.

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

Experience

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.

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.

Implementation and Tests

Voting instructions

Fill out the appropriate ballot(s) below and mail it/them to me <anton@mips.complang.tuwien.ac.at>. 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.

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

Ballot for systems

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). 
[ ] 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.
If you want to provide information on partial implementation, please do so informally, and I will aggregate this information in some way.

Ballot for programmers

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. 
[ ] 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.
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.
Anton Ertl