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.
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.
gcc gave an error because the `char *` parameter doesn't match the
`const char *` in the prototype of regsave(). clang didn't give an
error. I added the prototype in commit 5301cce.
This breaks all machines because the declared return type void
disagrees with the implicit return type int (when I compile mach.c
with clang). Unbreak i386, i80, i86, m68020, powerpc, vc4 by adding
the return types to mach.c. We don't build any other machines; they
are broken since commit a46ee91 (May 19, 2013) declared void prolog()
and commit fd91851 (Nov 10, 2016) declared void mes(), with both
declarations in mach/proto/ncg/fillem.c.
Also fix mach/vc4/ncg/mach.c where type full is long, so fprintf()
must use "%ld" not "%d" to print full nlocals.
directories --- wrangling descr files was too hard. C programs can be built
for cpm, pc86, linux386, linux68k!
--HG--
branch : dtrg-buildsystem
rename : util/ack/build.mk => util/led/build.mk
rename : util/LLgen/build.mk => util/topgen/build.mk
These files "magically reappeared" after the conversion from CVS to
Mercurial. The old CVS repository deleted these files but did not
record *when* it deleted these files. The conversion resurrected these
files because they have no history of deletion. These files were
probably deleted before year 1995. The CVS repository begins to record
deletions around 1995.
These files may still appear in older revisions of this Mercurial
repository, when they should already be deleted. There is no way to fix
this, because the CVS repository provides no dates of deletion.
See http://sourceforge.net/mailarchive/message.php?msg_id=29823032
