meissner@osf.org (Michael Meissner) (05/07/90)
In article <3217@yogi.oakhill.UUCP> marvin@oakhill.UUCP (Marvin Denman) writes: | In article <11259@netcom.UUCP> woolsey@netcom.UUCP (Jeff Woolsey) writes: | >Could someone enlighten me about the design decision in the 88100 where | >the "Signed Integer Divide" instruction causes exceptions if either of | >its operands are negative?? This seems counter-intuitive and useless, | >and I suspect driven by real-estate issues. What's the real reason? | > | >-- | >-- | >Jeff Woolsey Microtec Research, Inc +1 408 980-1300 | >...!apple!netcom!woolsey ...!amdcad!sun0!woolsey | | As I remember it this is how the decision was made. The divider circuitry | assumes unsigned division since floating point is sign magnitude. Therefore | early in the architectural definition cycle only unsigned integer division was | supported. The implementation changes necessary for signed integer division | were evaluated and were judged to have lengthened what was considered a | critical speedpath or increased the pipelining complexity greatly by adding an | extra stage for signed integer division. We decided that future implementations | might want to correctly support signed division so we defined the opcode to | allow easy upwards compatibility. Later on we noticed that a reasonable | fraction of the cases (>=25%) could be supported with the existing hardware | with very minimal changes. The decision was made to support divs in this manner | rather than always trapping. | | In summary, the decision was driven slightly by real estate, but more in | concerns over potential critical paths. It is likely but not guaranteed that | future implementations will fully support divs in hardware. I agree with you | that the code generated by most compilers to avoid divs is pretty gross looking, | but a cleaner alternative is available if you are willing to often trap on divs. I don't know beans about hardware, but I am a compiler jock, and I worked for about a year on the GNU C compiler for the 88k at Data General. IMHO, this is the worst decision made about the 88k, bar none. From a purists point of view, having a signed divide instruction that doesn't handle negative numbers is pure travesity. From a more pragmatic point of view, it caused severe contortions in the compiler, which I will attempt to explain below. I could have lived with the divide pipeline extending 1-5 cycles if it would just get the #@!$ correct answer, since the compiler now has to put in code to get the signs right, and that code takes a minimum of 5 extra cycles to execute (two bcnd's, whose delay slot can be filled with the negation of the values for use on signed divides + 1 br to the final common code). The code space for the divides can start chewing up space, and this makes programs a little bigger, which mean they might use more pages.... Doing all the if's and branchs has another effect on the compiler -- this code must be exposed to the full compiler in general, in order to properly allocate the two extra temps to hold the negative values. This in general means that the compiler loses that the operation all the ifs do is a divide, and it has trouble removing loop invarient divides from loops, and for constant propigation discovering a divide really produces a constant result. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Catproof is an oxymoron, Childproof is nearly so