Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!decwrl!ucbvax!MITCH.ENG.SUN.COM!wmb
From: wmb@MITCH.ENG.SUN.COM
Newsgroups: comp.lang.forth
Subject: Floating point stack
Message-ID: <9008281422.AA00144@ucbvax.Berkeley.EDU>
Date: 28 Aug 90 06:32:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: wmb%MITCH.ENG.SUN.COM@SCFVM.GSFC.NASA.GOV
Organization: The Internet
Lines: 35

> The end result of the compromise in the proposal that was adopted is that,
> rather than some of the existing floating point code needing to be
> rewritten to be portable, ALL OF IT WILL HAVE TO BE.  From the standpoint
> of portability, all existing floating point code is broken.  Period.

Yeah, I guess so.  OTOH, you could just declare that the code has an
environmental dependency on a floating point stack, which is no worse
than the current situation (in which there is no floating point standard).
(Yeah, yeah, I know, the environmental dependency sucks too)

> I admired the handling of the Floored vs. Truncated division compromise,
> but this one sucks hot rocks from hell.  ...
> I scanned several dozen screens of code with various floating-point
> calculations and encountered many instances where the existence
> of a separate stack is vital to running the code.

> This is one area where the TC should have bitten the bullet and made a
> definite decision for or against a separate stack.

Sigh.  What to do?  The committee seemed to be pretty much set on a
separate stack, but then Phil Koopman came and made an impassioned
and eloquent plea for not requiring a separate stack.

Sometimes I feel like this is a "damned if you do, damned if you don't"
situation.

My personal position favors specifying a separate stack, but Phil was
pretty persuasive.  I convinced myself that I could manage to write
new portable code in the ambiguous situation, and at that point my
position softened somewhat.

Mitch Bradley, wmb@Eng.Sun.COM

(getting somewhat weary of defending one half of the Forth community
 against the other half, and vice versa)