> > P Witte wrote: > > While were talking fp, can someone please explain what the purpose of the > > $81f bias (or whatever the technical term) is? Why not just represent > > exponents as +/-32k ? > > > > Per > > > >
Lau replied > > It's a bit "historic", I suspect. > More than that, it is very historic! The original routines were written by Jan Jones - to meet three constraints: 1 program compactness, 2 interpreter compactness on an integer only processor 3 interpreter speed on an integer only processor The 68xxx series is 16 bit word oriented (even on the 68008 8 bit bus version) so a whole word exponent makes sense. But, by using only 12 bits for the exponent (enough for astonomical callculations) the 4 MSBs can be used as the "floating point number token" flag without needing to use an extra word in to flag a floating point number - a 25% space saving for almost no cost. At the time, "mass storage" was of the order of 100 kbytes, not the 100 Gbyte today. > > It allows all operations on the exponent to be done with unsigned > arithmetic, which saves some brain work when implementing the stuff. > Saving brainwork also means saving time and cost > It gives an easy test for a "magic" value of zero exponent, which is > handy for the "special" cases. If is were not biased, you would have to > use a value like "0x8000", which would become messy. > A floating point value = 0.0 is 6 bytes of zero - not just neat but economical > The specific bias varies, but to some extent is one that preserves a > balance of mantissa precision for maximum and minimum absolute values. > It is generally just one off what you'd expect. > > Note that, with the IEEE format, operations on both exponent and > mantissa are unsigned (as it uses a separate flag to indicate > positive/negative value). The QDOS implementation is somewhat of a > hybrid, as it uses signed arithmetic for the mantissa. No it's not hybrid, both exponent and mantissa are "signed", its just the the offset ensures that the exponent is never stored negative - it can become negative during the calculations, but if it does, the mantissa is denormalised to bring the exponent back to zero. > I suspect Sinclair adopted that format to make the code a fraction > quicker. Naaa, Jan Jones did it > By doing so (instead of using the "concealed leading bit"), you lose one > bit of precision (and introduce the "invalid representation" problems), > but you can write shorter, more straightforward software code. The IEEE > format is expected to be done by harware, which can happily > "re-manifest" the concealed leading bit of the fly. I'm waffling a bit > here... but if QL used a concealed leading one on a 32-bit mantissa, it > would have to do 33-bit arithmetic all the time. 33 bit arithmetic would be almost as expensive as 64 bit arithmetic in calculation - a major cost for a small benefit I have always suspected that IEEE format was defined by a committee whose primary object was to ensure that "standard" floating point numbers could not be handled efficiently in either software or microcoded hardware using simple integer operations. The idea being to force the use of excessively complex and expensive FPUs even for simple calculations. The result was that a few years ago, Intel FPUs were relatively slow and full of odd bit errors (from Pentium onwards, they seem to have improved), Sun FPUs were ridulously expensive, while Motorola FPUs were fast. Motorola cheated by performing an IEEE to Motorola special format before trying to perform calculations. Tony Tebby
