13 Mar
2016
13 Mar
'16
3:16 p.m.
I haven't gone through your code in great detail. In particular I'm
not sure what your rounding algorithm is (towards zero, round to
nearest, etc.) I don't see what you're using the guard bit for, I
would expect it to be appended to the mantissa prior to addition
and rounding. Whether that's significant would depend on how you
expect the rounding to work.
Two suggestions (which you may well have tried):
1. Try an extra guard bit.
2. Convert to sign+magnitude so you don't have to worry about negative
mantissas (i.e. negate a negative mantissa before shifting and back
again after alignment).
Lawrence
On 13/03/16 21:39, Charles Anthony wrote:
The Multics distribution includes ISOLTS, a
surprisingly complete and
pedantic processor test program.
It is unhappy with our emulated floating point.
This should be the floating point used by the GE 6xx series and the
Honeywell DPS8 and 6000 series.
There is one particular failure that I am driven to seeking help for.
If the intricacies of mainframe floating point math h/w do not interest
you, time to delete this message and move on.
For add and subtract operations, the operand with the smaller has its
mantissa shifted right and the exponent incremented adjusted until the
exponents match.
From the DPS8M assembly language manual:
"The mantissas are aligned by shifting the mantissa of the operand
having the algebraically smaller exponent to the right the number of
places equal to the absolute value of the difference in the two
exponents. Bits shifted beyond the bit position equivalent to AQ71 are
lost."
Sadly, ISOLTS complains about our implementation. It does helpfully provide
what it says are the correct answers. Examination of the answers reveals
the it is not the case that the shifted bits are lost; the shift mantissas
are rounded according to rules that I can't quite characterize.
ISOLTS runs many operands through the UFA (Unnormalized Floating Add)
instruction; the current state of my rounding algorithm passes the first 46
tests; fails on the 47th. Everytime I try a different approach, it fails on
an earlier test.
The best rule that I have is: if the shifted mantissa is all ones and at
least one of the bits shifted out was a one, the set the mantissa to 0.
Test #47 adds:
700000000000700000000000 E 31. to
202025452400000000000000 E 102.
ISOLTS expects
202025452377 777777777777 E 102.
and it gets:
202025452400000000000000 E 102.
The emulator should not have rounded in this case; but I cannot figure out
the rule.
I've abstracted the instruction out of the emulator and embedded it in a
standalone test harness that runs the 47 tests.
https://sourceforge.net/projects/dps8m/files/drop/Charles/ufa47.c
Any insights, suggestions for algorithms, reading material would be greatly
appreciated.
-- Charles
--
Lawrence Wilkinson lawrence at ljw.me.uk
The IBM 360/30 page http://www.ljw.me.uk/ibm360