The code used `sphl` to set the stack pointer, but the correct value
was in de, not hl. Fix by swapping the values of de and hl, so `sphl`
is now correct. When we shrink an integer from 4 to 2 bytes, both
registers de and hl point to copies of the result, but only one
register preserves the stack below the result.
This fixes writehex() in tests/plat/lib/test.c, when I compile it with
ack -mcpm, so it preserves the pointer to "0123456789abcdef", so it
writes hexadecimal digits and not garbage.
This bug goes back to commit 157b243 of Mar 18, 1985, so the bug is
32 years old, and probably the oldest bug that I ever fixed.
I compiled tests/plat/lib/test.c with ack -mcpm, but i80 ncg did emit
wrong code in writehex(uint32_t) for
"0123456789abcdef"[code & 0xf]
The code called '.and' to evaluate `code & 0xf`, then tried to call
'.cii' to narrow the result from 4 to 2 bytes, but it passed garbage
instead of 4 to '.cii'. The rule for '.and' was
pat and defined($1)
kills ALL
uses dereg={const2,$1}
gen Call {label,".and"}
This failed to kill register de={const2,4}, so ncg pushed de,
expecting to push 4, but actually pushing garbage.
Fix such rules using `mvi a,...` or `lxi de,...` so ncg doesn't track
the token in the register. This is like the i86 table. A different
fix would use a dummy instruction `killreg a` or `killreg de` like the
m68020 table.
Also correct 1 to $1 when calling '.exg'.
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
