The new .seek assembler pseudo-op advances the location
counter to a fixed offset within a section --- or to a fixed
address, if the section is a .base'd section. It works
somewhat like the GNU assembler's .org pseudo-op, though
with a hopefully less confusing name.
This pseudo-op lets us avoid having to manually compute the
needed boot sector padding in the pc86 start-up code
plat/pc86/boot.s .
The follows( ) function uses pa->os_lign when determining
whether an output section pa immediately follows another
section pb.
However, emits( ) was not using this alignment information
when laying out and padding the output sections. This seems
to be a bug.
I suspect that mach/arm/cv/cv.c might need a similar fix.
This should fix at least some instances of the "undefined
reference to `LLnc_recover'" error that happens in some
builds (https://github.com/davidgiven/ack/issues/218).
The bug was that genname( ) used a static `namebuf' buffer
and did not properly check for overflow when writing into
it. The result was that the `non_corr' variable was
sometimes overwritten with a non-zero value when it should
be zero, causing bogus results later.
This proposed patch makes genname( ) dynamically allocate
and resize a buffer for holding a target file name.
I also take this chance to fix a typo in correct_prefix().
bug caused by this instruction:
fmove.l fp0,d0
problem was caused by a conflict between the fpu emulator (softfloat) and the compiler.
the emulator implemented this as a purely arithmetic move & conversion,
but the compiler assumed that the result could be interpreted as a logical (ie unsigned) conversion.
rightly or wrongly.
for example, if fp0 contained the value 2576980377.0 which is unsigned integer -1717987328
the emulator would treat this as an integer overflow and move 0x7fffffff (INT_MAX) into d0.
The complier on the other hand would assume that d0 contained 2576980377 (the unsigned value).
I don't know which is correct, but this is my fix for the time being.
problem was implementation of fint & fintrz floating point ops in m68kfpu.c
Both these ops truncated the integer to 32 bits instead of leaving it as an extended precision floating point number
Changed the implementation to use 64 bit ints instead of 32 bit ints.
latest version of musashi engine
includes floating point emulation
(plus a few patches to add in missing opcodes needed by ack - see tags JFF & TBB)
added a few missing linux syscalls in sim.c
pascal now runs pretty well
quick test with modula2 passes
c gets the floating point numbers wrong, so more work needed here
other languages untested
plat/linux68k/emu/build.lua is probably not quite right - the softfloat directory is compiled in the wrong place
left_shift() adapts the example from @davidgiven that caused `ack -O3`
to crash. multiply() is a similar example.
Edit the build system to use -O3 for this test. It now takes -O3 from
the test's filename, and still defaults to -O0.
The strength reduction (SR) phase mishandled the END pseudo when SR
found at least 2 different expressions in the same loop, and SR made a
new header for the loop.
Since 1987 (commit 159b84e), SR appended the new header to the end of
the procedure. Later, SR fixed the header by adding a BRA branch to
the loop's entry, and moving the END pseudo from the previous basic
block to the header. If SR found multiple expressions, it called
fix_header() multiple times, and tried to move the END again. The
extra move failed assert(INSTR(e) == ps_end), or moved another line
after the END, so opt2 (the peephole optimizer) would crash.
Fix by removing fix_header() and moving the code to make_header(), so
SR adds the BRA and moves the END when it makes the header, and does
so only once for each header.
Adjust init_code(), which inserts code into a header. Stop checking
for an empty header, because make_header() now adds BRA. After
inserting code before BRA, don't move LP_INSTR, because later
insertions should go before BRA, not after END.
Our build enables assertions in some other ACK tools (like assemblers
and LLgen), but disabled them in ego until now. Bug #203 becomes a
failed assertion in ego's SR phase:
sr: util/ego/sr/sr_reduce.c:483: fix_header: Assertion
`INSTR(e) == ps_end' failed.
Comment out 2 assertions in util/ego/share, because they fail on
systems with 4-byte int, 8-byte long.
Calls like `debug("something\n", 0, 0, 0, 0)` cause clang warnings,
because debug() is a macro that passes its arguments to printf(), and
clang warns about extra 0s to printf(). Silence the warnings by
hiding the printf() in a new function do_debug(). The code still
passes extra 0s to printf(), but clang can't warn.
Macros debug() and verbose() should use C99 __VA_ARGS__, so they don't
require the extra 0s; but ACK doesn't use __VA_ARGS__ yet.
Adjust some format strings for debug() or fatal(), or cast their
arguments, to match their types. I don't know whether uint32_t is
unsigned int or unsigned long, so I cast it to unsigned long, and
print it with "%lx".
In util/led/sym.c, #include "save.h" to declare savechar(), and use
parentheses to silence a clang warning in hash().
Most warnings are for functions implicitly returning int. Change most
of these functions to return void. (Traditional K&R C had no void
type, but C89 has it.)
Add prototypes to most function declarations in headers. This is
easy, because ego declares most of its extern functions, and the
comments listed most parameters. There were a few outdated or missing
declarations, and a few .c files that failed to include an .h with the
declarations.
Add prototypes to a few function definitions in .c files. Most
functions still have traditional K&R definitions. Most STATIC
functions still don't have prototypes, because they have no earlier
declaration where I would have added the prototype.
Change some prototypes in util/ego/share/alloc.h. Functions newmap()
and oldmap() handle an array of pointers to something; change the
array's type from `short **` to `void **`. Callers use casts to go
between `void **` and the correct type, like `line_p *`. Function
oldtable() takes a `short *`, not a `short **`; I added the wrong type
in 5bbbaf4.
Make a few other changes to silence warnings. There are a few places
where clang wants extra parentheses in the code.
Edit util/ego/ra/build.lua to add the missing dependency on ra*.h; I
needed this to prevent crashes from ra.
Fixes https://github.com/davidgiven/ack/issues/188
One call to n_coerc() omits the 6th and last argument. This worked in
traditional K&R C, but stops working if we declare n_coerc() with a
prototype of all 6 parameters.
Change the last parameter to a pointer. Declare n_coerc() with
prototype, so it now requires all 6 arguments. Pass NULL when have no
iocc_t. This NULL exists only to satisfy the prototype; n_coerc()
will not use this NULL.
A different fix would declare n_coerc() with 5 parameters and `...`,
then use <stdarg.h> to read the 6th argument when it exists.
If a .c file included "types.h" before "mach.h", then it missed the
declaration of mach_option(). Fix by adding "xmach.h".
Fix mach/powerpc/ncg/mach.h and mach/vc4/ncg/mach.h to use the correct
type in their printf() format strings.
Also add `static` and remove `register` in mach/proto/top/top.c. A
static function is only in one file, so its function declaration may
go in that file, instead of a header file.
Use the new syntax in the mips, pdp, powerpc tables to declare
functions before calling them. These declarations prevent compiler
warnings about implicitly declaring functions. They also provide
prototypes of the function parameters.
Also fix a warning in the powerpc table: use `bsearch(...) != NULL` to
avoid converting the pointer from bsearch() to an int.
The syntax for topgen is a block `{...}` among the parameters in the
top table. It looks like the syntax of LLgen, but topgen doesn't
allow nested blocks, so declarations like `struct whatever {...};`
don't work. The token OPEN_BRACKET that begins a declaration_block
doesn't conflict with the LETTER that begins a parameter_line or the
'%' that begins a separator.
Because a block writes a #line command to gen.h, a parameter line now
also writes a #line command to gen.h, so it doesn't get a wrong line
number from a previous block.
Use switch.h to reduce warnings from clang about implicit declarations
of functions. I used `grep ... do_*.c | sed ... | sort`, and some
manual editing, to make the big list of Do???() functions.
Edit C code to reduce warnings from clang. Most warnings are for
implicit declarations of functions, but some warnings want me to add
parentheses or curly braces, or to cast arguments for printf().
Make a few other changes, like declaring float_cst() in h/con_float to
be static, and using C99 bool in ego/ra/makeitems.c and
ego/share/makecldef.c. Such changes don't silence warnings; I make
such changes while I silence warnings in the same file. In
float_cst(), rename parameter `str` to `float_str`, so it doesn't
share a name with the global variable `str`.
Remove `const` from `newmodule(const char *)` in mach/proto/as to
silence a warning. I wrongly added the `const` in d347207.
For warnings about implicit declarations of functions, the fix is to
declare the function before calling it. For example, my OpenBSD
system needs <sys/wait.h> to declare wait().
In util/int, add "whatever.h" to declare more functions. Remove old
declarations from "mem.h", to prefer the newer declarations of the
same functions in "data.h" and "stack.h".
Use C89 size_t for sizes from sizeof() or to malloc() or realloc().
Remove obsolete (unsigned) casts. Sizes were unsigned int in
traditional C but are size_t in C89.
Silence some clang warnings. Add the second pair of round brackets in
`while ((ff = ff->ff_next))` to silence -Wparentheses. Change
`if (nc_first(...))/*nothing*/;` to `(void)nc_first(...);` to silence
-Wempty-body. The code in compute.c nc_first() had the form
`if (x) if (y) s; else t;`. The old indentation (before 10717cc)
suggests that the "else" belongs to the 2nd "if", so add braces like
`if (x) { if (y) s; else t; }` to silence -Wdangling-else.
Shuffle extern function declarations. Add missing declaration for
LLparse(). Stop declaring RENAME(); it doesn't exist. Move some
declarations from main.c to extern.h, so the C compiler may check that
the declarations are compatible with the function definitions.
Assume that standard C89 remove() is available and doesn't need the
UNLINK() wrapper.
In lib/incl, don't need to include <stdio.h> nor <stdlib.h> to use
assert().
Remove alloc.h. If you don't clean your build, then an outdated
BUILDDIR/obj/util/LLgen/headers/alloc.h will survive but should not
cause harm, because nothing includes it. Don't need to remove alloc.h
from util/LLgen/distr.sh, because it isn't there.
Run the bootstrap to rebuild LLgen.c, Lpars.c, tokens.c.
The ACK builds an internal LLgen without installing it. The new
target would rebuild LLgen's own parser using the ACK's internal
LLgen. Keep bootstrap.sh, which uses an installed LLgen. The new
target is more convenient for those who build the ACK but don't build
and install a separate LLgen.
This will cause ACK libc to provide int64_t as long (instead of long
long) on LP64, if we ever get such a platform.
LP64 would have 64-bit long and 64-bit long long, so int64_t might be
either type. For example on amd64, int64_t is long in NetBSD libc,
and long long in OpenBSD libc. Support for long long in ACK remains
incomplete (no printf "%lld"), so it seems better to prefer long where
possible. Also, int64_t being long before long long is more
consistent with int32_t being int before long.
Put suffixes on the values of INT32_MAX, INT64_MAX, and related
constants, so they have the same types as int32_t and int64_t.
Most machines had undefined valu_t and redefined it to a different
type. Edit mach/*/as/mach0.c to remove such redefinitions, so the
next change to valu_t will affect all machines.
Edit mach/proto/as/comm0.h to change valu_t to int64_t, and add
uvalu_t and uint64_t.
Remove int64_t y_valu8 from the yacc %union, now that valu_t y_valu
can hold 64 bits. Replace y_valu8 with y_valu. The .data8 pseudo
becomes less special; it now accepts absolute expressions.
This change simplifies the assembler and seems to have no effect on
the assembled output. Among the files in share/ack/examples, the only
changes are in hilo_bas.* and startrek_c.linuxppc, but those files
seem to change whenever I rebuild them.
This allows `long long x; switch (x) {...}` in C. Add test in C.
This adapts the code for csa 8 and csb 8 from the existing code for
csa 4 and csb 4, for both i386 and m68020.
Shifts that drop an EM word don't need to coerce the word to REG.
Some arithmetic right shifts can use _cdq_.
Drop rules for illegal integer conversions. Sizes below a word are
illegal in EM, except as the source size of _cii_.
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.
