Difference between revisions of "Writing portable code regarding the processor architecture"
| Line 7: | Line 7: | ||
Some processors generate hardware processor exceptions when data is badly aligned. | Some processors generate hardware processor exceptions when data is badly aligned. | ||
(e.g. Alpha or ARM). Sometimes the hardware exceptions are caught and fixed using emulation by the OS, but this is very slow, and should be avoided. This can also cause records to have different sizes, so always use sizeof(recordtype) as size of a record. If you define packed record, try to ensure that data is naturally aligned, if possible. | (e.g. Alpha or ARM). Sometimes the hardware exceptions are caught and fixed using emulation by the OS, but this is very slow, and should be avoided. This can also cause records to have different sizes, so always use sizeof(recordtype) as size of a record. If you define packed record, try to ensure that data is naturally aligned, if possible. | ||
| + | |||
| + | To check if the CPU requires proper alignment, check the FPC_REQUIRES_PROPER_ALIGNMENT define. On 32 Bit CPUs this usually means that data up to a size of 4 must be naturally aligned. If you've to access unaligned data, use the move procedure to move it to a aligned location before processing it. The move procedure takes care of unaligned data and handles it properly. | ||
== 32 Bit vs. 64 Bit == | == 32 Bit vs. 64 Bit == | ||
Revision as of 00:38, 22 March 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 or ARM). Sometimes the hardware exceptions are caught and fixed using emulation by the OS, but this is very slow, and should be avoided. This can also cause records to have different sizes, so always use sizeof(recordtype) as size of a record. If you define packed record, try to ensure that data is naturally aligned, if possible.
To check if the CPU requires proper alignment, check the FPC_REQUIRES_PROPER_ALIGNMENT define. On 32 Bit CPUs this usually means that data up to a size of 4 must be naturally aligned. If you've to access unaligned data, use the move procedure to move it to a aligned location before processing it. The move procedure takes care of unaligned data and handles it properly.
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.
