27 Jul
2008
27 Jul
'08
4:39 p.m.
Hi,
I am trying (and failing) to learn how AMOS Basic (and Amiga's) store floating point
numbers. Whilst it is clear that it uses Motorola Fast Floating Point (MFPP) I have been
unable to get it to work based on an equation found online (the Amiga RKRM's all say
to use the FPP functions in the maths libraries, and also confirm the layout - 24 bit
mantissa, 1bit sign, 7bit exponent).
Am I doing something wrong with my maths??
Formula:
FP result =[(-1)^SIGN] * [2^(EXP - 0x40)] * [MANTISSA / 0x1000000]
0x1000000 = 16,777,216
0x40=64
floating-point variable value=0.5
Binary value of variable=%10000000 00000000 00000000 01000000
Values calculated using formula (above):
SIGN=0 (positive)
EXPONENT=64 - 64 (bias) = 0
MANTISSA=2.51658 E+07 / 16,777,216 = 1.5
Thus:
result = [(-1)^SIGN] * [2^(EXP - 0x40)] * [MANTISSA / 0x1000000]
= [(-1)^0]*[2^(0)]*[1.5]
= 1*1*1.5
= 1.5!
I have uploaded a bitmap image of my maths to my site if it isn't clear from above
what I am doing.
http://www.geocities.com/aliensrcooluk/public/MFPP_problem.bmp
Please help!
Andrew B
aliensrcooluk at yahoo.co.uk
28 Jul
28 Jul
12:40 a.m.
Andrew,
Where does the 2.51658E+07 come from? The mantissa of %10000000
00000000 00000000 = 8388608 which would come out right.
Is the "Binary value of variable" what you actually see (by looking at
memory) for a variable which is printed as 0.5?
Is there something going on with normalisation, where the top "1" bit is
assumed and omitted? If the value had been 1.5 and your calculation
worked out as 0.5 that would be an explanation, so maybe I'm
interpreting this backwards.
Lawrence
On Sun, 2008-07-27 at 21:39 +0100, Andrew Burton wrote:
Hi,
I am trying (and failing) to learn how AMOS Basic (and Amiga's) store floating point
numbers. Whilst it is clear that it uses Motorola Fast Floating Point (MFPP) I have been
unable to get it to work based on an equation found online (the Amiga RKRM's all say
to use the FPP functions in the maths libraries, and also confirm the layout - 24 bit
mantissa, 1bit sign, 7bit exponent).
Am I doing something wrong with my maths??
Formula:
FP result =[(-1)^SIGN] * [2^(EXP - 0x40)] * [MANTISSA / 0x1000000]
0x1000000 = 16,777,216
0x40=64
floating-point variable value=0.5
Binary value of variable=%10000000 00000000 00000000 01000000
Values calculated using formula (above):
SIGN=0 (positive)
EXPONENT=64 - 64 (bias) = 0
MANTISSA=2.51658 E+07 / 16,777,216 = 1.5
Thus:
result = [(-1)^SIGN] * [2^(EXP - 0x40)] * [MANTISSA / 0x1000000]
= [(-1)^0]*[2^(0)]*[1.5]
= 1*1*1.5
= 1.5!
I have uploaded a bitmap image of my maths to my site if it isn't clear from above
what I am doing.
http://www.geocities.com/aliensrcooluk/public/MFPP_problem.bmp
Please help!
Andrew B
aliensrcooluk at yahoo.co.uk
--
Lawrence Wilkinson lawrence at ljw.me.uk
The IBM 360/30 page http://www.ljw.me.uk/ibm360
4:50 p.m.
Thanks to Lawrence and Lee, I solved the problem.
I was getting the mantissa value by reading the longword with an offset of -1. However the
byte before the mantissa had a value of 1, thus adding 16777216 to the value when read in
with the mantissa! Oops.
I shall check my code more carefully next time :)
Regards,
Andrew B
aliensrcooluk at yahoo.co.uk
5:12 p.m.
I am trying (and failing) to learn how AMOS Basic (and
Amiga's) store
floating point numbers. Whilst it is clear that it uses Motorola Fast
Floating Point (MFPP) I have been unable to get it to work based on an
equation found online (the Amiga RKRM's all say to use the FPP
functions in the maths libraries, and also confirm the layout - 24 bit
mantissa, 1bit sign, 7bit exponent). Am I doing something wrong with
my maths??
IF it is the same as IEEE single precision,
there is a sign bit,
and 23 bits to store a 24 bit mantissa, (normalization always forces the
highest bit on, so there is no need to store it),
and an 8 bit exponent (with 128 offset)
Zero, therefore, has to be stored as a special case.
6:56 p.m.
Fred Cisin wrote:
IF it is the same as IEEE single precision,
there is a sign bit,
I don't know much about the Amiga, but I think he said it was using
Motorola's Fast Floating Point library (MC68343). That doesn't use IEEE
format natively, though it includes functions to convert to and from
IEEE format.
The FFP was not IEEE because by using a nonstandard encoding they were
able to get higher performance.
Eric
5910
days inactive
5911
days old
4 comments
4 participants
participants (4)
-
aliensrcooluk＠yahoo.co.uk -
cisin＠xenosoft.com -
eric＠brouhaha.com -
ljw-cctech＠ljw.me.uk