Add rules for 8-byte integers to m68020 ncg. Add 8-byte long long to
ACK C on linux68k. Enable long-long tests for linux68k. The tests
pass in our emulator using musahi; I don't have a real 68k processor
and haven't tried other emulators.
Still missing are conversions between 8-byte integers and any size of
floats. The long-long tests don't cover these conversions, and our
emulator can't do floating-point.
Our build always enables TBL68020 and uses word size 4. Without
TBL68020, 8-byte multiply and divide are missing. With word size 2,
some conversions between 2-byte and 8-byte integers are missing.
Fix .cii in libem, which didn't work when converting from 1-byte or
2-byte integers. Now .cii and .cuu work, but also add some rules to
skip .cii and .cuu when converting 8-byte integers. The new rule for
loc 4 loc 8 cii `with test_set4` exposes a bug: the table may believe
that the condition codes test a 4-byte register when they only test a
word or byte, and this incorrect test may describe an unsigned word or
byte as negative. Another rule `with exact test_set1+test_set2` works
around the bug by ignoring the negative flag, because a zero-extended
word or byte is never negative.
The old rules for comparison and logic do work with 8-byte integers
and bitsets, but add some specific 8-byte rules to skip libem calls or
loops. There were no rules for 8-byte arithmetic, shift, or rotate;
so add some. There is a register shortage, because the table requires
preserving d3 to d7, leaving only 3 data registers (d0, d1, d2) for
8-byte operations. Because of the shortage, the code may move data to
an address register, or read a memory location more than once.
The multiplication and division code are translations of the i386
code. They pass the tests, but might not give the best performance on
a real 68k processor.
The assembler wrongly defined _bfexts_ and _bfffo_ with the same bits
as _bfextu_; this turned all bfexts and bfffo instructions into
bfextu. Motorola's 68k Programmer's Reference Manual (1992) gives
different bits for bfexts, but still has wrong bits for bfffo. Change
bfexts and bfffo to match the 68k emulators musahi, aranym, syn68k.
The bitfield width is from 1 to 32, not 0 to 31, so move the warning
from 32 to 0. This doesn't change the warning message, so it will say
that 0 is "too big", when 0 is really too small.
Add EXACT to the rule for adi 8, in the same way that the old rules
for and 8, ior 8, xor 8 have EXACT.
Add rules for sli 8 and sru 8 when shifting 32 bits, and add
assertions in llshift_e.c to test these rules.
My i386 code from 893df4b gave the wrong sign to some 8-byte
remainders. Fix by splitting .dvi8 and .rmi8 so each has its own code
to pick the sign. They and .dvu8 and .rmu8 share a private sub
.divrem8 for unsigned division.
Improve the i386 code by using instructions like _bsr_ and _shrd_.
Change the helpers to yield a quotient in ebx:eax or a remainder in
ecx:edx; this seems more convenient, because _div_ puts its quotient
in eax and remainder in edx.
Add tests for comparisons and shifts. Also add enough integer
conversions to compile the shift test (llshift_e.c), and disable
some wrong rules for ldc and conversions.
This provides adi, sbi, mli, dvi, rmi, ngi, dvu, rmu 8, but is missing
shifts and rotates. It is also missing conversions between 8-byte
integers and other sizes of integers or floats. The code might not be
all correct, but works at least some of the time.
I adapted this from how ncg i86 does 4-byte integers, but I use a
different algorithm when dividing by a large value: i86 avoids the div
instruction and uses a shift-and-subtract loop; but I use the div
instruction to estimate a quotient, which is more like how big integer
libraries do division. My .dvi8 and .dvu8 also set ecx:ebx to the
remainder; this might be a bad idea, because it requires .dvi8 and
.dvu8 to always calculate the remainder, even when the caller only
wants the quotient.
To play with 8-byte integers, I wrote EM procedures like
mes 2, 4, 4
exp $ngi
pro $ngi,0
ldl 4
ngi 8
lol 0
sti 8
lol 0
ret 4
end
exp $adi
pro $adi,0
ldl 4
ldl 12
adi 8
lol 0
sti 8
lol 0
ret 4
end
and called them from C like
typedef struct { int l; int h; } q;
q ngi(q);
q adi(q, q);
This turns EM `con 5000000000I8` into assembly `.data8 5000000000` for
machines i386, i80, i86, m68020, powerpc, vc4. These are the only ncg
machines in our build.
i80 and i86 get con_mult(sz) for sz == 4 and sz == 8. The other
machines only get sz == 8, because they have 4-byte words, and ncg
only calls con_mult(sz) when sz is greater than the word size. The
tab "\t" after .data4 or .data8 is like the tabs in the con_*() macros
of mach/*/ncg/mach.h.
i86 now uses .data4, like i80. Also, i86 and i386 now use the numeric
string without converting it to an integer and back to a string.
This takes literal integers, not expressions, because each machine
defines its own valu_t for expressions, but valu_t can be too narrow
for an 8-byte integer, and I don't want to change all the machines to
use a wider valu_t. Instead, change how the assembler parses literal
integers. Remove the NUMBER token and add a NUMBER8 token for an
int64_t. The new .data8 pseudo emits all 8 bytes of the int64_t;
expressions narrow the int64_t to a valu_t. Don't add any checks for
integer overflow; expressions and .data* pseudos continue to ignore
overflow when a number is too wide.
This commit requires int64_t and uint64_t in the C compiler to build
the assembler. The ACK's own C compiler doesn't have these.
For the assembler's temporary file, add NUMBER4 to store 4-byte
integers. NUMBER4 acts like NUMBER[0-3] and only stores a
non-negative integer. Each negative integer now takes 8 bytes (up
from 4) in the temporary file.
Move the `\fI` and `\fP` in the uni_ass(6) manual, so the square
brackets in `thing [, thing]*` are not italic. This looks nicer in my
terminal, where italic text is underlined.
This causes clang to give fewer warnings of implicit declarations of
functions.
In mach/pdp/cv/cv.c, rename wr_int2() to cv_int2() because it
conflicts with wr_int2() in <object.h>.
In util/ack, rename F_OK to F_TRANSFORM because it conflicts with F_OK
for access() in <unistd.h>.
unsigned comparisons is surprisingly not that useful due to marshalling
overhead; it's only four bytes to do inline (plus jc), or six for a constant.
Also add some useful top optimisations. Star Trek goes from 39890 to 39450
bytes.
