Hi, Markus! On Fri, 1 Feb 2002, Markus Nullmeier wrote:
Now the point I was going to make is simply to update the CLN documentation.
Maybe. I'll try to think up a formulation.
As for the debatable optimization I made in the posted patches, I totally agree to use cl_value_len there.
weird (hypothetical?) system with alignment = 8 and sizeof(long) = "32 bits" will break the documented behaviour :-/
well, that would mean cl_value_len = 29 insted of the normal cl_value_len = 30 for 32 bit architectures and cl_value_len = 32 for 64 bit architectures,
if my interpretation of CLN's header didn't fail (but such failure is quite likely anyway...): 4-byte alignment eats 2 bits, 8-byte alignment eats 3 bits off cl_value_len, at least for 32 bit architectures.
No, your interpretation did not fail, at least as long as you refer to the value of cl_word_alignment. See below...
And, the headers get the architecture idea from something like sizeof(long) in intparam.h: e.g. #define long_bitsize 32 (made by autoconf, I guess).
Yes, intparam.h is generated by compiling and running intparam.cc while running configure.
Pointer size and alignment==8, but sizeof(long)==4, hmmm, dunno what would
I don't know if (Pointer size) != sizeof(long) will work for CLN's headers.
Okay, just for the record: I have never heard of any 64-bit machine which does not adhere to the LP64-model. Has anybody else?
I was thinking of Pointer size = 4 and alignment = 8. Maybe I'm a fool and anybody will prove that there were never such systems and never will be...
Well, we should see if anybody really comes up with something thus pervert and just fix the header <cln/object.h> then... ...by dropping the macro cl_word_alignment into <cln/object.h> as usual. I am talking about lying, here. We can simply tell CLN the alignment is actually 4. Nothing is spoiled if the system never sets this additional bit in the malloc'ed address. They can even make it 12, 16, 20 or 128 if they think this is a bright idea, as long as the last two bits are not set. ;-) Sounds reasonable?
have to be changed... What do you say is gonna break there? (BTW, the
The only thing that would break on these non-existing (?) system is the "quick conversion" from C++'s int to CLN's cl_I, for values of e. g. 2^28, contrary to the documentation. Therefore IMHO CLN's documetation could be updated to speak of 2^(cl_value_len-1) instead of 2^29.
OTOH, if you compute with int variables you need to be careful in C, anyways: int x = 1000000; int y = x*x; is not a mistake but anybody who expects y to be equal to 1000000000000 then is naive, at best. This limit just happens to be pushed down from 2^32 to 2^29.
Anybody still reading? Markus
Even answering! -richy. -- Richard B. Kreckel <Richard.Kreckel@Uni-Mainz.DE> <http://wwwthep.physik.uni-mainz.de/~kreckel/>