[fpc-pascal] 32 to 64 bits

[Marco van de Voort]

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
 
> 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 ?

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)

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

Pascal calculates by default in signed arithmatic.
 
> 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.

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.
 
> "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" ? :-?

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.