13 Mar
2016
13 Mar
'16
1:39 p.m.
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
13 Mar
13 Mar
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
3:47 p.m.
On Sun, Mar 13, 2016 at 3:16 PM, Lawrence Wilkinson <ljw-cctech at ljw.me.uk>
wrote:
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.
I was experimenting with the IEEE rounding algorithms, which are driven by
guard bit, last bit, sticky bit; I left that data collection in place.
Using sticky bit got the best results.
You're not sure what the rounding algorithm is because I don't know what it
should be.
Two suggestions (which you may well have tried):
1. Try an extra guard bit.
if mantissa negative and the last 3 bits shifted out are ones, then round
(for this
case, set the mantissa to 0)?
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).
[So far] the only test failures have been with negative mantissas, so I
don't think that I gain anything by going to sign-and-magnitude; I'd be
tracking zeros being shifted off instead of ones, which it isn't going to
change the rounding algorithm, just the implementation.
-- Charles
3:48 p.m.
They may effectively have a "sticky" bit, similar to that used in IEEE
754 FP. A sticky bit is used when shifting an operand right; if any
one bits are shifted into the stick bit position, the sticky bit
becomes 1, but shifting a zero into it does not clear it to zero. IEEE
754 uses the sticky bit to implement correct rounding.
In this case, if there's a sticky bit it would prevent a non-zero
operand mantissa that is shifted right from ever actually reaching
zero. If that operand is negative, that might result in the behavior
you're seeing, where one ULP is being subtracted from the other
operand.
3:52 p.m.
On Sun, Mar 13, 2016 at 3:48 PM, Eric Smith <spacewar at gmail.com> wrote:
They may effectively have a "sticky" bit,
similar to that used in IEEE
754 FP. A sticky bit is used when shifting an operand right; if any
one bits are shifted into the stick bit position, the sticky bit
becomes 1, but shifting a zero into it does not clear it to zero. IEEE
754 uses the sticky bit to implement correct rounding.
In this case, if there's a sticky bit it would prevent a non-zero
operand mantissa that is shifted right from ever actually reaching
zero. If that operand is negative, that might result in the behavior
you're seeing, where one ULP is being subtracted from the other
operand.
'sticky bit' is what got me through to the 47th test, so it's close but not
quite right. (Assuming I implemented it correctly. "if shifted mantissa is
all ones and any ones were shifted out, then set the mantissa to 0".)
-- Charles
14 Mar
14 Mar
7:23 a.m.
On Mar 13, 2016, at 4:39 PM, Charles Anthony
<charles.unix.pro at gmail.com> 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.
You may need to examine the schematics rather than rely on the manual. It's all too
common that the manual only describes a rough approximation of reality.
A very nice in depth treatment of an old floating point implementation is here:
"Design and correctness proof of an emulation of the floating-point operations of the
Electrologica X8: a case study" by F.E.J. Kruseman Aretz -
http://repository.tue.nl/674735 . That's a different machine, obviously, but it might
give you some ideas to explore.
Still, rather than experiment with different implementations to look for one that passes
diagnostics, working from the real design seems like the best approach. IEEE float
algorithms may not be all that helpful; IEEE float came much later.
paul
27 Mar
27 Mar
7:43 p.m.
On Sun, Mar 13, 2016 at 1:39 PM, Charles Anthony <charles.unix.pro at gmail.com
wrote:
The Multics distribution includes ISOLTS, a
surprisingly complete and
pedantic processor test program.
It is unhappy with our emulated floating point.
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.
After many helpful suggestions and analyses, the missing piece of the
rounding algorithim has been identified:
Only round if the mantissa was shifted more then 71 bits.
Many thanks,
-- Charles
3191
days inactive
3206
days old
6 comments
4 participants
participants (4)
-
charles.unix.pro＠gmail.com -
ljw-cctech＠ljw.me.uk -
paulkoning＠comcast.net -
spacewar＠gmail.com