Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!SUN.COM!wmb From: wmb@SUN.COM Newsgroups: comp.lang.forth Subject: Re: Standard follies Message-ID: <8907181614.AA06989@jade.berkeley.edu> Date: 18 Jul 89 04:35:57 GMT Sender: daemon@ucbvax.BERKELEY.EDU Reply-To: Forth Interest Group International List Organization: The Internet Lines: 144 Funny, I usually agree with Phil, but not this time... > 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. The problem is that Forth tends to "overload" bitwise logical operators and boolean operators, especially AND, OR, and NOT, whereas e.g. C and Fortran don't. (Okay, Forth does indeed distinguish between 0= and NOT, but it is common practice, athough wrong, to use NOT to complement a flag) Here is the hard problem (assuming a 16-bit machine for the sake of discussion): Suppose you have a bit mask whose value is (hex) 8000. You want to test a value to see if that bit is clear. So we try this: ( value ) 8000 and 0= IF THEN This code works correctly on a 2's complement machine. However, it fails on a 1's complement machine, because 8000 is negative zero, so "8000 0=" is true! What is needed is a an unsigned 0= operator! On a 2's complement machine, U0= and 0= would be equivalent. On a 1's complement machine, 0= is true if its operand is either +0 or -0, and U0= is true if its operand is +0, i.e. all bits are 0. In C, you can get this effect either by declaring the data type of the value to be tested to be unsigned, or by using bit field operations. It irks me that it is *not possible* to write clean portable code in standard Forth (conditional compilation is not clean, in my book), due to too few operators, thus forcing the existing operators to do double duty and thus to have "surprise" implementation dependencies. The problem is even worse with address arithmetic, since there are many popular machines with strange addressing (where "strange" is defined as "not linearly byte-addressed"). The Forth standard implicitly assumes linear byte addressing, because it provides only the word "+" for both number arithmetic and for address arithmetic. (The proposed "CELL+" is a step in the right direction, but it goes only about 20% of the way). > in hardware. Why should innocent users pay performance > penalties for division that doesn't work like the stuff > they learned in grade school? Playing devil's advocate, I know of no computer hardware that works like the stuff they teach in grade school. In grade school, they teach infinite-precision arithmetic. > Floored division should be available as an optional, software- > supported extension, as Mitch suggested. I would actually hope that Forth vendors would not make it optional. The standard really ought to define required words for both options. An implementation could choose which one of them is implemented most efficiently, and then implement the other in software. That way, if I want to write a portable program, I don't have to worry about whether or not any particular machine has one or the other of the words. > 3) Separate floating point stack -- too expensive > ... > 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. I think it's shortsighted to assume that the word size is going to stick at 32 bits. > Should folks who are serious about floating point > performance pay penalties to remain compatible with > 16-bit machines? Most people who are really serious about floating point performance don't want to deal with stacks at all, regardless of whether it is a separate floating point stack or the regular parameter stack. They want to convolve vectors, or to perform pipelined transformations, or to evaluate n-dimensional neighborhoods. > 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. That is not the point. A very good programmer can easily do such things, but real significant software progress will only be be made when people don't have tweak and port everything that comes their way. > I think the separate floating point stack was spawned > by the fact that the 8087 had one that clever programmers exploited. I think it's because the combinatorics of 16/32 integer size X single/ double/extended floating point size makes people's brains hurt when they thing about the stack manipulations. I have implemented floating point packages for several different fp chips and boards, none of which has a hardware fp stack. I used a separate floating point stack because it simplifies a lot of things, especially when users would like to select the precision without having to code the problem differently. > I think you will find other hardware designers in > agreement. I know Chuck Moore agrees with the floating > point stack issue. Forth isn't getting creamed in the marketplace because of hardware problems. It's getting creamed because (a) nobody is training Forth programmers to any significant extent, and (b) the lack of standardized libraries and usage across different Forth implementations causes continuous reinvention of wheels; forward progress is slow in the community sense. The purpose of a standard ought to be to allow the creation of portable programs. Specific hardware doesn't have to directly implement the standard. It can implement whatever the designer can sell. However, the software that runs on that hardware should implement the standard. Providing additional features or faster modes is fine, so long as the standard semantics are also available. Cheers, Mitch