Difference between revisions of "Writing portable code regarding the processor architecture"
| Line 1: | Line 1: | ||
| − | There are | + | There are several main issues when writing code which is portable regarding the processor architecture: endianess and 32 vs. 64 Bit processors. |
== Endianess == | == Endianess == | ||
| + | |||
| + | == Alignment == | ||
| + | |||
| + | Some processors generate hardware processor exceptions when data is badly aligned. | ||
| + | (e.g. Alpha). Sometimes the hardware exceptions are caught and fixed using emulation by the OS, but this is very slow, and should be avoided. | ||
== 32 Bit vs. 64 Bit == | == 32 Bit vs. 64 Bit == | ||
Revision as of 23:49, 19 January 2004
There are several main issues when writing code which is portable regarding the processor architecture: endianess and 32 vs. 64 Bit processors.
Endianess
Alignment
Some processors generate hardware processor exceptions when data is badly aligned. (e.g. Alpha). Sometimes the hardware exceptions are caught and fixed using emulation by the OS, but this is very slow, and should be avoided.
32 Bit vs. 64 Bit
To achive a maximum compatiblity with older code, FPC doesn't change the size of predefined data types like integer, longint or word when changing from 32 to 64 Bit. However, the size of a pointer is 8 bytes on a 64 bit architecture so constructs like longint(pointer(p)) are doomed to crash on 64 bit architectures. However, to allow you to write portable code, the FPC system unit introduces the types PtrInt and PtrUInt which are signed and unsigned integer data types with the same size as a pointer.
