If the command line option yus to allow the underscore character in
symbols is NOT selected, then interpret underscore as a new binary
operator meaning to do a left shift of the left side value by the
number of bit positions indicated by the right side value. As for the
arithmetic operators, both values must be literal (numeric constants
or symbols equated to a numeric constant).
I haven't done much compatibility testing with MACRO11 to check
weirdnesses, but the original functionality is very limied: none
of the mnemonics has operands.
The comment "eat first char of illegal label, else endless loop on
implied .WORD" was no longer true. It did reveal some other small
gotchas, which are corrected now as well.
There was an obscure bug in parse_expr(), used to evaluate 'if df',
where it could skip past the end of the line marker.
If this happened inside an expanded macro, then after that was the
next line...
In other cases it might be worse.
Now that this is fixed, another check for line end junk can be enabled.
which have an general (source) argument and an AC destination.
There are no FPP instrs which have 1 general source arg;
only with 1 general destination (even TSTF).
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.
