This brings in David Given's PowerPC changes, including the addition
of the modern code generator (mcg) for PowerPC.
Resolve minor conflicts in top build.lua and util/led/main.c
This header declares functions in libobject. Our programs never
included object.h, but called functions in libobject without declaring
them. So, our build system never put object.h in the include path;
any #include <object.h> would fail to find the header.
With this commit, a program may #include <object.h> if it has
modules/src/object+lib in its deps.
Declare structs in object.h so we can use them in prototypes without
gcc warning, "'struct whatever' declared inside parameter list".
Remove inclusion of ansi.h from object.h. Programs would need to
depend on modules+headers to get ansi.h in the include path.
This fixes flt_arith2flt() when sizeof(arith) != 4, where arith is
long. When cemcom.ansi sees an expression like d + 1 (where d is some
double), it calls flt_arith2flt() to convert 1 to floating-point. On
machines where sizeof(arith) != 4, the code did n >>= 1 when n should
not have been changed. If n was 1, then n == 0 became true. This
caused the code to convert 1 or -1 to 0.0.
My fix assumes sizeof(arith) >= 8, so I can use n >> 32. Machines
with sizeof(arith) of 5 to 7 would need to do (uarith)n >> 32, where
uarith must be an unsigned integer type of same size as arith.
In startrek.c, the Enterprise can now dock with a starbase. The
compiler no longer translates s1 - 1 to s1 - 0.0 and s1 + 1 to s1 +
0.0, so the game now looks for starbases next to the Enterprise.
It seems that someone wanted to build flt_arith with a compiler that
had long but not unsigned long. This required extra code to
accomplish unsigned right shift, unsigned division, and unsigned
comparison using the signed operations. Now that we use uint32_t, we
can simply use the unsigned operations and remove the ucmp() function.
We have similar code in mach/proto/fp/ and in
lang/cem/libcc.ansi/stdlib/ext_comp.c where we use the unsigned
operations.
Some long variables become uint32_t, and some masks with 0xFFFFFFFF
disappear because uint32_t has only 32 bits.
Update flt_arith.3 to show that mantissa uses uint32_t.
Provide a target to install modules/src/flt_arith/test.c as flt_test
so I can run the tests.
This seems to fix an error when flt_arith converts a literal
double-precision float to IEEE format. For example, 0.5 and 0.75 got
converted to slightly below their correct values.
My host gcc for amd64 has 64-bit long, but flt_arith needs only 32
bits. The code (at least flt_add.c) can make 32-bit overflows. Such
overflows would set the higher bits of a 64-bit long, which might
cause problems later.
I need to use uint32_t and not int32_t because the code still uses
long, and the sign extension from int32_t to long would cause
problems. The mantissa represents a value in [0, 2) that can't be
negative, so unsigned type is better. Also, signed overflow is
undefined behavior in C, so flt_add.c better make overflows with
uint32_t and not int32_t.
This commit doesn't touch lang/cem/libcc.ansi/stdlib/ext_fmt.h which
continues to use unsigned long for its mantissa fields.
the number of types of relocation possible in the object file. (Now,
hopefully, working.)
Also change the object serialiser/deserialiser to never try to read or
write raw structures; it's way safer this way and we don't need the
performance boost any more.
--HG--
branch : default-branch
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
I already did this in abebf1586c06, but I edited the wrong file. Then
in edddc6b7cd17, I deleted that file.
By fixing fit16i(), I can now compile ACK for OpenBSD/amd64.
