Mainframe floating point math implementation.

Lawrence Wilkinson ljw-cctech at
Sun Mar 13 17:16:00 CDT 2016

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).


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.
> Any insights, suggestions for algorithms, reading material would be greatly
> appreciated.
> -- Charles
> -- 
> Lawrence Wilkinson                          lawrence at
> The IBM 360/30 page         

More information about the cctech mailing list