Hello FPC-Pascal,

Can anybody help me understanding the variables which will be different (in size) in 32 and 64 bits versions, and which ones are "size fixed" across platform bits ?

So the question, something like a table:

32 64
unsigned 16 bits WORD? WORD?
signed 16 bits X X
unsigned 32 bits DWORD? DWORD?
signed 32 bits Integer? Integer?
unsigned 64 bits QWORD? QWORD?
signed 64 bits Int64? Int64?
Native "integer" X? X?

Where LongInt fits ? Bits dependent or not ?

Maybe a table is available in the wiki, but I was unable to find it.

Thank you.

In our previous episode, JoshyFun said:

Afaik most is in the docs, but some short pointers:

32 64
unsigned 16 bits WORD? WORD?
signed 16 bits see table docs (smallint/shortint) unsigned 32 bits DWORD? DWORD?
signed 32 bits compiler mode dependant 16/32 unsigned 64 bits QWORD? QWORD?
signed 64 bits Int64? Int64?
Native "integer" "native" is ambiguous.
Signed integer as big
as pointer PtrInt Ptrint
Unsigned integer as big
as pointer PtruInt Ptruint

"native" is confusing since it can taken in many ways. Native as in most performance? Register size? Addressing size? Addressing size + segment ? (size_t, ssize_t).

Where LongInt fits ? Bits dependent or not ?

always 32-bit signed.

Maybe a table is available in the wiki, but I was unable to find it.

The docs are the primary source, the language ref should have a table somewhere near the start. I sometimes use it, because I always forget which is 8-bit signed and which is 16-bit signed. (which is why I never use them and always use ctypes)

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.

In our previous episode, JoshyFun said:

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.

First, if you don't know the 64-bit memory model discussions have a look here:

http://www.stack.nl/~marcov/buildfaq/buildfaq.html#x1-660005.1

which is a summary (in case you want more background) of

http://queue.acm.org/detail.cfm?id=1165766

No. There are multiple choice, and the normal integer type usually stays 32-bit. Only the type equivalent to pointer scales. (in our case, in the C case, there were even more possibilities)

Pascal calculates by default in signed arithmatic.

Not necessarily. There are processors that need two memory cycles to fetch a full word. Moreover, using 64-bit everywhere blows up your data size unnecessarily (you are constantly shoveling those 32 generally empty zeros in every word around)

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").

The integer _type_ is 16/32 only, depending on mode. 16-bits in TP modes, 32-bit in Delphi (-like) modes. Note that in general all whole numbers types (except for comp in some cases) are also classified as the "integer" types family.

Current always, but may change ? Perfect English. Now so, but not guaranteed to last forever. This pegging is mostly for Delphi compatibility (and then specially the Windows headers). If you don't have that, it doesn't matter so much.

The most important part to remember is to always use ptrint/ptruint for pointers, but preferably also for differences of pointers. (e..g when walking memory). There might be breaking changes for future freak platforms, but the fact that pointer size changes is the main issue of 64-bit systems now.

Because of these weak definition of types (which is very confusing IMO) I often use a check in the implementation part of units if I have to reliy on sizes:

if sizeof(Word)2    then Halt(9000);
if sizeof(DWord)4   then Halt(9001);
if sizeof(LongInt)4 then Halt(9002);
etc.

Then I am at least warned in case my presumption are no longer valid.

Jürgen Hestermann.

In our previous episode, J�rgen Hestermann said:

The only one variable to my knowledge are pointer, integer, ptrint and ptruint. Integer with compiler mode, and the others with 32/64bit