by using long double where available.
Unfortunately, it won't be available everywhere, so a better solution
would still be nice.
Also, sometimes rounding of smaller sizes doesn't work right yet.
Fix gitlab issue #5.
The parse_float() function has several bugs:
1. For 1- and 2-word floats it will always write all 4 bytes if the value is
exactly 0.
2. It incorrectly rounds and normalizes 1- and 2-word floats.
To see the issue easily try the following inputs:
.flt2 1.0
.flt4 1.0
These will assemble as '040100 000000' and '040200 000000 000000 000000'.
They should both begin '040200'.
In fact the test file test/test-prec.mac is incorrect in its only floating point value:
.word ^f 1.5 ; 040140
should actually assemble as 040300, not 040140 (040140 is actually ^F0.875).
I confirmed this on RT-11 running MACRO V05.06.
I fixed the problem with the following deltas:
[the patch]
The most crucial change is the very last one. 0x200000000000 is actually (1 << 45)
and because ufrac is normalized it means that it will always downshift ufrac by 1.
Because of this corrected sequence:
575 000000 lctbas = .
576 000000 genlct seq
1 000001 lc.seq= 1
- 2 .rept <.-lctbas>/2
+ 2 000000 .rept <.-lctbas>/2
3 lc.seq= lc.seq+lc.seq
4 .endm
- 1 000002 lc.seq= lc.seq+lc.seq
5 000000 073631 .rad50 /seq/
6 .if nb <>
7 lcinit= lcinit+lc.seq
8 .endc
The repeat count is 0. lc.seq previously incorrectly had a value of 2
but now it has the correct value of 1.
This has a knock-on effect on various other expressions throughout, so there
are various changes.
This is most relevant in implied .WORD directives which are caused by an
attempt to call a macro (which happens to be undefined) with arguments
that don't parse as valid expressions.
