Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!uunet!ogicse!zephyr.ens.tek.com!tekchips!tekgvs!toma
From: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Newsgroups: comp.lang.forth
Subject: Re: Floating Point
Message-ID: <8594@tekgvs.LABS.TEK.COM>
Date: 13 Dec 90 21:50:28 GMT
References: <2112.UUL1.3#5129@willett.pgh.pa.us>
Reply-To: toma@tekgvs.LABS.TEK.COM (Tom Almy)
Organization: Tektronix, Inc., Beaverton,  OR.
Lines: 44

In article <2112.UUL1.3#5129@willett.pgh.pa.us> Ray Duncan writes:
>    >Besides Harris, I believe LMI... uses a floating point
>    >implementation without a floating point stack

> That's right.  Our "official" versions of software floating point and
> hardware-assisted floating point do not maintain the numbers on a
> separate stack.

> For those people who need the last drop of performance, we have a
> separate version of our hardware floating point implementation available
> for downloading on our BBS which maintains the floating point values on
> the Intel 80x87 floating point stack and allows explicit chaining of
> calculations on the separate stack.

I wrote this version to support an "experimental" floating point version
of the Native Code Compiler. (The NCC compiles colon definitions as
CODE words or subroutines, and has been commercially available either
from LMI or myself since 1983 in versions for the Z80, 80x86 and 80386
protected mode).

The 80x87, being a stack processor, is ideal for executing Forth floating
point. In fact, native code compiled floating point calculations are
roughly as fast as direct-threaded-interpreted integer calculations (80386/7).
It hardly made sense to compile the code to move the numbers between the
stacks, which involves a data conversion in the x87, especially when most
Forth floating point primitives could compile to a single 80x87 instruction.
In order to allow native code and threaded code floating point functions to
coexist I rewrote the standard LMI package. Other than changing the bottom
level code words I only had to make one other change attributable to the
use of two rather than one stack. I feel the debate over separate stacks
is highly overrated!

The resulting floating point code compared highly favorably (sometimes
several times faster, and never slower) to the available C compilers (MS 5.0,
Borland 1.5) at the time doing matrix multiplication and other similar
operations and beat or matched these compilers in accuracy tests. While
the C compilers have gotten smarter in using the 80x87 stack, they still
don't match what can be done with native code compiled Forth. Just the
ability to multiprogram (interleave fp and integer calculations) makes for
a win.

Tom Almy
toma@tekgvs.labs.tek.com
Standard Disclaimers Apply