Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!van-bc!rsoft!mindlink!a684 From: a684@mindlink.UUCP (Nick Janow) Newsgroups: comp.lang.forth Subject: Re: Floating point stack Message-ID: <2979@mindlink.UUCP> Date: 28 Aug 90 18:07:09 GMT Organization: MIND LINK! - British Columbia, Canada Lines: 64 As I see it, the present compromise on FP numbers makes applications portable; the same FP code will run on an RTX2001 and an 8086&8087. In return for this portabiity, the programmers must accept the restraint that once a FP number is placed on the stack (you must assume the data stack), anything below it on the stack can not be accessed. Programmers for the RTX series must accept this restriction as well; do any want to comment on how that affects their work? Anyone who doesn't follow this is writing non-portable code. I don't know how difficult the restriction on data stack access will be, especially for large FP applications. Locals and the return stack can solve some of the problems, but I'd like to hear the comments of programmers who use FP heavily in their work _after_ they try it under the new restrictions, using locals and the return stack. koopman@a.gp.cs.cmu.edu (Philip Koopman) writes: > Historically, separate floating point stacks have come into use because of > implementation considerations on specific platforms (e.g. the 80287). There's another reason for a separate stack: the length of a FP number differs from application to application (and from machine to machine). Using conditional FP words (Flength 48 = IF MAKE OVER 3 CELLS ...) sounds very messy to me. :( > One motivator for separate stacks is that 16-bit integers are not the same > size as 32-bit reals. On 32-bit hardware, this problem goes away: single and > double precision for reals and ints are the same size. (80-bit reals are > brought to you courtesy of Intel, and are uncommon elsewhere). If you are > really serious about fast floating point (i.e., single-cycle F* and F+), you > probably should be using a 32-bit machine, so I do not weight this reason > heavily. <<>> One idea I had during the discussion of FP handling was the option of having a separate FP stack _and_ allowing single-cell FP operations on the data stack. In this manner, single-cell FP could be handled either way, or if separate words are used for each operation (Ff+ and Fd+) you could have both. This would allow fast single-cell operations and slower but more accurate 80 bit operations at the same time. Either one could use a coprocessor. While this method would allow separate-stack programmers and combined (32 bit) stack programmers to write efficient code, it wouldn't allow equally fast implementation on the other's systems. Also, it would make systems with stacks narrower than a FP number (32 bits?) unhappy. Of course, if the portability of an application was a high priority, the restrictions of the present compromise could still be followed. If the restrictions weren't followed, the program will be ANS standard, environment dependent. I find this method appealing for some reason, but I have to admit that the present ANS compromise seems better. Under the restrictions, the ANS code will run on stack machines or non-stack machines equally fast. Wait a minute! If I remember correctly, the ANS compromise says something along the lines of "The default is separate FP stack, with the restriction of not accessing stack items below a FP item." Well, if you obey that restriction, why bother calling it a separate stack? If I sound confused on the issue of FP, that's okay, because I am. :-) Anyways, I wanted to put out the idea of separate FP stack _and_ single cell FP operations. If nothing else, it may help clarify why certain options are workable/unworkable. I find writing these things out helps me clarify my own thoughts. Maybe it will also inspire others to come up with other ideas that haven't been considered yet.