Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!pt.cs.cmu.edu!a.gp.cs.cmu.edu!koopman From: koopman@a.gp.cs.cmu.edu (Philip Koopman) Newsgroups: comp.lang.forth Subject: Standard follies Keywords: floored division, 1's complement, floating point stack Message-ID: <5438@pt.cs.cmu.edu> Date: 7 Jul 89 12:32:25 GMT Organization: Carnegie-Mellon University, CS/RI Lines: 84 OK, here's a stack processor architect's $.02 about the proposed Forth Standard. Normally I don't like getting into the fray, but the recent discussion, and the fact that someone might actually listen to me have convinced me to participate. 1) 1's complement. -- not required. 1's complement machines still exist. I believe that the AN/UYK-7 uses 1's complement, and it is still installed on most of the US Navy fleet (1960's technology -- scary, isn't it?) But, the point is, who cares? Does the ANSII C standard worry about integer representation? Does the FORTRAN standard? Why must it be specified? People who want to write portable code should be careful not to exploit specific machine behavior, in any language. If people are worried about writing code that depends on the 2-ness of the complement, then they have four choices: - Don't exploit the integer representation explicitly - Let the code break on 1's complement machines - Use run-time tests to execute correct code - Use conditional compilation to compile correct code 2) Floored division -- make it optional I agree that there are some instances where floored division is nice to have. However, it is inherently slower and more difficult to perform. Hardware has usually been built to support truncated division, because the hardware is simpler (and therefore faster, and less prone to obscure bugs). I do not have any plans to support floored division in hardware. Why should innocent users pay performance penalties for division that doesn't work like the stuff they learned in grade school? Anyone who needs floored division knows it. They can easily define an alias to make it the default. Floored division should be available as an optional, software- supported extension, as Mitch suggested. 3) Separate floating point stack -- too expensive I have tried to talk to members of the committee about this, notably Martin Tracy, but they have turned a deaf ear. A separate floating point hardware stack is too expensive to implement in hardware. I have no plans on implementing such a stack. It seems to me that the primary appeal of such a stack is that floating point numbers used to be a different size than integers. However, this problem goes away with 32-bit processors. Single integers are the same size as single floats, and the same with doubles. Should folks who are serious about floating point performance pay penalties to remain compatible with 16-bit machines? Let's face it, processors with 16-bit ALUs will never be very good at IEEE-format floating point math! Again, conditional compilation can solve the transportability issue between 16-bit and 32-bit systems for folks who care about such things. I ported a floating point math package written for a 16-bit processor (with absolutely *no* thought given to portability) to a 32-bit processor in about 2 hours. And, I used a common stack for integers and floats. I think the separate floating point stack was spawned by the fact that the 8087 had one that clever programmers exploited. But, there is more to the world than the 80x86/7! If standard Forth requires a separate floating point stack, I do not plan on building standard Forth hardware. Summary: Don't make hardware and compiler designers life more difficult, and in particular, don't make hardware more expensive/slower and software more expensive/slower by specifying behavior that usually doesn't matter. Things such as 1's complement and floored division should be options, not requirements. I think you will find other hardware designers in agreement. I know Chuck Moore agrees with the floating point stack issue. How about a comment from Marty or John at Johns Hopkins/APL? Phil Koopman koopman@greyhound.ece.cmu.edu Arpanet 5551 Beacon St. Pittsburgh, PA 15217 This is completely my own opinion, and in no way represents anything having to do with Harris Semiconductor (don't tell them I posted this -- they might shoot me).