Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!ucsd!ucbvax!CGEUGE54.BITNET!BARTHO
From: BARTHO@CGEUGE54.BITNET ("PAUL BARTHOLDI, OBSERVATOIRE DE GENEVE")
Newsgroups: comp.lang.forth
Subject: Re: Floating point stack
Message-ID: <4061F7EE06FF00182F@cgeuge54.bitnet>
Date: 30 Aug 90 15:31:00 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 60

Hi friends,

>    Thanks, Philip, for the response.  You have made several good points,
> although I still find room to quibble (don't we all? :-).  I don't
> see much point in going back and forth on this with 100 lines of text
> at a pop (did you hear that, OOF debaters?).
       100 agree !  Thanks again.
>    Let me just reiterate my basic point about why the decision to allow
> either a single or a separate floating point stack in a Standard System is
> a very bad one.
       idem !
>    It is difficult, if not impossible, to write floating point code that will
> run portably on each of the following implementations:
>
>    16-bit integers, 32- and 64-bit FP, unified stack
>    16-bit integers, 32- and 64-bit FP, separate stack
>    32-bit integers, 32- and 64-bit FP, unified stack
>    32-bit integers, 32- and 64-bit FP, separate stack
>
I was one of those who suggested back in Rochester 1981 to have separate
stacks.  My reasons were (and still are) : - To keep full precision of 80x87
and similar chips (including 9911 etc), data MUST stay as long as possible
on the hardware stack;  - mixing on the same stack integer and floating is
(from experience, I have FP on my forth since 1976 ...) either trivial because
they don't interfer, or terrible because the right data is never at the right
place on the stack, so the code becomes full of 'unnecessary' ROT ROLL etc.
- The computing speed may be real for some hardware (80x87 for example) but
was not important in my case (HP1000 with FP microcode).

Interestingly, the 'trivial' case is independant of unified or separate stack,
while the 'terrible' is almost 100% solved with separate ones.  It is very
clear to me that we need a single choice, either separate or unified (I prefer
separate; why, see above!).  I don't want to write and DEBBUG code for both
version (with conditionals etc the problem is not technical, but practical!)

> The end result will be that although the code may be ANSI Standard Forth, ther
   e
> is no guaruntee whatsoever that floating point operations will be portable.
> Granted, this is the same as our current position, but some solution should
> have been arrived at; instead the TC did nothing.
>    Even though I am strongly in favor of the separate stack for coding ease
> and -- yes -- computing speed, I would have accepted a Standard that forced
> the FP numbers to the data stack.  It is the lack of a definitive answer that
> is the real error.
>
> -- Lee Brotzman (FIGI-L Moderator)

Please, TAKE a decision NOW  (we should have done it in 1981)!

                              Regards,                  Paul.

     +--------------------------------------------------------------+
     |  Dr Paul Bartholdi             bartho@cgeuge54.bitnet        |
     |  Observatoire de Geneve        bartho@obs.unige.ch           |
     |  51, chemin des Maillettes     02284682161350::bartho (psi)  |
     |  CH-1290 Sauverny              20579::ugobs::bartho          |
     |  Switzerland                   +41 22 755 39 83       (fax)  |
     |                                +41 22 755 26 11     (phone)  |
     |                                +45 419 209 obsg ch  (telex)  |
     +--------------------------------------------------------------+