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).
mlb-rt11.c: In function 'mlb_rt11_entry':
mlb-rt11.c:284:27: warning: 'ent' may be used uninitialized in this function [-Wmaybe-uninitialized]
buffer_resize(buf, ent->length + 1); /* Make it large enough */
~~~^~~~~~~~
It is spurious because ent gets initialized in the loop above.
If the loop is never executed, this must be because 0 >= mlb->nentries
and NULL is returned, so the buffer_resize() is never reached.
mlb-rsx.c: In function 'mlb_rsx_entry':
mlb-rsx.c:374:23: warning: 'ent' may be used uninitialized in this function [-Wmaybe-uninitialized]
fseek(mlb->fp, ent->position, SEEK_SET);
~~~^~~~~~~~~~
It is spurious because ent gets initialized in the loop above.
If the loop is never executed, this must be because 0 >= mlb->nentries
and NULL is returned, so the fseek() is never reached.
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.
