IBM Mainframe Forum

Hi guys,

how to define one floating point number in HLASM? for example, how to define one variable whose value is 5.06?
and how does computer know where decimal point locates(here, it locates between 5 and 0)?
thx.

Sincerely,
Bob

HLASM allows use of DC E'5.06' or DC D'5.06' or DC L'5.06' where E is single-precision floating point, D is double-precision floating point, and L is quad-precision floating point. You can EASILY read about all three in the HLASM Language Reference manual, found (among other places) here http://publib.boulder.ibm.com/infocenter/zos/v1r11/index.jsp?topic=/com.ibm.zos.r11.asma400/asmr1020.htm

The computer knows where the decimal point is the same way for floating point as for any other number -- you tell it. Note that the internal representation of a floating-point 5.06 will look nothing like 5.06 so do not expect to see that value in your assembled code.

Mr. Sample is correct.The first 7 bits are the sign and a power of 2 exponent; the remaining 24 bits represent the "mantissa". To add the two numbers, the computer first adjusts the second number so the exponents are equal.
3FF5C28F -> 400F5C28 -> 4100F5C2. It then adds the adjusted mantissas 500000+ 00F5C2 = 50F5C2 and then inserts the exponent 41. Then it shifts the mantissa and adjusts the exponent so the first 4 bits of the mantissa are not 0. Notice there is no decimal point as such in this arithmetic.

Translating the 4150F5C2 so it prints as 5.06 is non trivial; I won't try to discuss it here.

Notice we lost the low order bits in the shifting at the beginning. IBM's first floating point implementation on the 704/709/7090/8094/7040/7044 worked similarly, but the exponent had 11 bits and the mantissa had 24 bits in a 36 bit word in storage and register. The right shift lost 1 bit for each 1 bit change in the exponent, compared to 4 bits for each 1 bit change in the exponent.

There was a huge stink about losing bits in the 1960s; IBM was forced to make a radical hardware change to minimize the effect; if you read the floating point section in Principles of Operation you will come across an extended discussion of "guard digits" that describes this change in detail.

I studied the issue about exponent and mantissa size very carefully in the 1960s. I came to these conclusions

• If the exponent had stayed at 11 bits, the mantissa would drop to 20 bits, and I think IBM judged that was too small.
• If they did 1 bit shifts with a 7 bit exponent, the number range would be too small. I figured out what the value range would have been; in 1966 I could do this then, but can't do it now, and the value range was pitiful.

The floating point Mr. Sample and I have been discussing is now called "hexadecimal" floating point to differentiate it from "binary" or "IEEE" floating point. The IEEE standard was developed in the 1980s, and Intel very successfully adopted it in a floating point co-processor used with the Intel 8088 / 8086 micro computer chips, and later incorporated into the Intel 80386 and later micro computer chips. IBM added IEEE floating point to the mainframes as an extension in the 1990s. There is also an IEEE decimal floating point standard which you can now use, but I know very little about this standard.

To correct yesterday's post.

4150F5C3 DC E'5.06'

The first 8 bits are a sign and a 7 bit exponent.

The fractional part of a floating point number is difficult to comprehend. In my discussion in my previous point I got two solutions, in essence, for E'5.06': the solution from the direct conversion performed by the Assembler, and the solution from adding E'5' and E'.06'; they were different by 1 bit. You should realize there is no exact conversion of 5.06 to any floating point.

After I wrote the post I attempted to perform the E'5.06' conversion to hex floating point. In 45 years this is the first time I've tried this. I won't go through the analysis here, but I'll give you a hint. Solve x/1048576=6/100, then convert the integer part of x to hex digits to get the fractional part of the number. 1048576 = X'100000' Where the X'100000' came from I'll leave to you to figure out. I got the same result as the Assembler, by the way. The Assembler is high, though the 1 bit lower result from doing E'5' + E'.06' is perfectly acceptable and just as correct as the Assembler's conversion.

recentlyk I do some research about it and got some conclusions:
1. The 1st bit indicates sign of the data: 0 represents '+' and 1 represents '-'.
2. The next 7 bits indicate exponent and the the decimal point's position(initial data is X'40', if the decimal point was shifted left 2 times, X'40'+X'2'=X'42'; If it was shifted right 1 time, X'40'-X'1'=X'3F').
3. The last 24 bits represent mantissa.



123.456 = 123 + 0.456 = X'7B' + X'0.74BC' = X'7B.74BC'

And then, shift the decimal point left 2 times until the decimal point is before the first digit except 0, so exponent bits were changed to X'40'+X'2'=X'42'.
For it is positive, the first bit is 0, so ECON2's 1st byte is still X'42', and so the whole memory of ECON2 is 427B74BC.

0.456 = X'0.74BC'' :

0.456 * 16 = 7.296
0.296 * 16 = 4.736
0.736 * 16 = 11.776
0.776 * 16 = 12.416

x / 65536 = 456 / 1000
x = 29884 = X'74BC'

4074BC6A -> 41074BC6 -> 420074BC
427B0000 + 420074BC = 427B74BC

Your notation seems strange to me because you persist in using a decimal point, but you do seem to have the idea.