Hello Marco, Saturday, January 10, 2009, 12:36:37 AM, you wrote:
MvdV> Afaik most is in the docs, but some short pointers: Sure :) but as I said not found :( and the information I had found does not describe the 32/64 bits differences. MvdV> 32 64 MvdV> unsigned 16 bits WORD? WORD? MvdV> signed 16 bits see table docs (smallint/shortint) MvdV> unsigned 32 bits DWORD? DWORD? MvdV> signed 32 bits compiler mode dependant 16/32 Hmmm... I was asking only for 32/64 differences (my targetted systems) but 16 bits is interesting also. For 32/64 this should be the LongInt do not ? MvdV> unsigned 64 bits QWORD? QWORD? MvdV> signed 64 bits Int64? Int64? MvdV> Native "integer" "native" is ambiguous. MvdV> Signed integer as big MvdV> as pointer PtrInt Ptrint PtrInt does not have too much sense :-? There are not negative memory addresses. MvdV> Unsigned integer as big MvdV> as pointer PtruInt Ptruint MvdV> "native" is confusing since it can taken in many ways. Native as in most MvdV> performance? Register size? Addressing size? Addressing size + segment ? MvdV> (size_t, ssize_t). Well, I understand "native" as the less efforce variable to be loaded/written to memory, in 32/64 bits usually it is the register size. >> Where LongInt fits ? Bits dependent or not ? MvdV> always 32-bit signed. And "integer" ? Is it always 32 bits ? Oh! I found the table in the documentation finally :) Integer is 16/32/64 bits (the thing I call it "native"). But there is something that I do not understand in this table. The doc says: "The cardinal type is currently always mapped to the longword type. The definition of the cardinal and integer types may change from one architecture to another and from one compiler mode to another." "Always" or "may change" ? :-? MvdV> The docs are the primary source, the language ref should have a table MvdV> somewhere near the start. I sometimes use it, because I always forget which MvdV> is 8-bit signed and which is 16-bit signed. (which is why I never use them MvdV> and always use ctypes) Yes, ctypes could be my solution too. Thank you for your help. -- Best regards, JoshyFun _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal