Frank Heckenbach wrote:
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 ...
Well, I belive that we can make GPI reader/writer both faster and more portable. For example we could bulk convert integers between endiannes, so that only folks that need comatibility will pay for it. But ATM I am looking low hanging fruits ...
- 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).
IIUC the most likely bug avoided due to checksums is reading inconsistent GPI file. That can be detected putting a random number (stamp) in the GPI header and checking that at the end of reading (or when the reader finds something wrong) the stamp is still the same. Still, a simple checksum should take less then 1% of compile time so we can live with it (BTW, backend folks are willing to risk serious bugs to get 1% speed improvement of the compiler).
Concering GP versus `--automake': I think we need to fix main automake problems if we want GP to work well. Basically:
1) to have separate GPI file for implementation (so that interface GPI stays consistent during compilation) 2) compile iterface and implementation separately (even if in the same file) 3) store dependencies in GPI files
For `--automake' specifically:
4) allow only _one_ compilation of given part, anyting more _is_ cyclic dependency, hence illegal (current way is just work-around for lack of 2)
For make (and possibly GP):
5) have option to print _all_ dependencies (includes + imports)
1, 3 and 5 could make GP both simpler and more reliable (AFAICS GP itself imlements/uses 2 and 4).
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.
I will have to check. My impression was that we just use adress we got from xmalloc, so it should be OK. Aligning data in GPI files my allow fullword access in GPI reader so it may be worthwile. But compute_checksum works on the whole buffer, so for it we only need a few bytes of zero padding at the end.
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.
Yes, we should store the size of gpi_int. But I think that gpidump can easily use this information at runtime to read "any" GPI file (but we should keep version check in place). Of course it costs time, but IMHO gpidump is not speed critical.