Waldek Hebisch wrote:
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.
Yes (both frontend and backend version). Much more in GPI files depends on endianness (besides checksums). We could detect and convert at runtime, but of course, it would slow down things even more (which I'm sure you wouldn't like too much, Adriaan). The only benefit would only to people who cross-compile *and* can't recompile on each host system for some strange reason ...
- 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).
As far as I'm concerned, feel free to change the checksums. I don't insist on the current algorithm (I think the comment in module.c doesn't really suggest I do ;-). But I wouldn't like to abandon checksums. AFAICS, they do catch some cases which would otherwise lead to obscure bugs. Perhaps GP will avoid such cases in the future (when all GP bugs are fixed :-), but even though --automake will then be faded out, such problems can still arise with hand-made make rules (which will probably always be used).
Also, please note that the buffer passed to compute_checksum is currently not aligned, so larger than byte-operations will be slow on some processors and invalid on the rest. But perhaps we should make is aligned. A consistent solution would be to round up each chunk (and the header) in a GPI file) to a multiple of the "word" size. This would add some code and add a few bytes in GPI files, but it's probably worthwhile.
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.
Yes. Since these types are no standard C types, it might not be so easy to get to them in a Pascal file.
We could store the size of the type used in the GPI file (similar to the endianness marker). The size itself can always be stored in 1 byte, especially if measured in bytes not bits, so no endianness and size issues here.
Then gpidump (and gpc) could at least give a proper error message on size mismatch. Or perhaps we could even extract the size at gpidump-build-time (perhaps in mk-t-inc) from a GPI file of one of the freshly compiled (with the target compiler) RTS units, and build gpidump using a matching `Cardinal attribute (size = ...)' type.
Frank