Adriaan van Os wrote:
Two more notes:
- compute_checksum_lladd is not endianness-neutral (but that may not
(yet) be a problem).
ATM gpi files depend on exact compiler version, so it seems reasonable to choose endianness of the compiler.
- gpidump.pas must be changed also, e.g. to match
compute_checksum_lladd
To make things clear: for gpc-20051104 I left the checksum "as is". I did not want to change the the checksum without looking at the consequences (need to change gpidump.pas is one of such consequences). At first I wanted just to replace current routine by an equivalent faster routine, but IMHO the speed tests does not give a clear winner (and changing checksum promises much higher gain anyway).
What I don't understand is that gpidump.pas uses the MedCard type, which is four bytes on Mac OS X.
type GPIInt = MedCard;
where gpc.h uses HOST_WIDE_INT, which is eight bytes on Mac OS X.
typedef HOST_WIDE_INT gpi_int;
gpidump is wrong. OTOH I am slightly surprised by Mac OS X values. Such values are typical for a cross compiler running on 32-bit machine but producing 64-bit code.
Using gpidump (with an unchanged gpc-200521104) returns "invalid endianness marker".
Looks like problem with the size of GPIInt.