On Tue, 4 Dec 2001, Frank Heckenbach wrote:
However, testing martin2a.pas on Sparc and MIPS revealed another problem. These processors (as typical for RISCs) have strict alignment requirements for word accesses, e.g., they can't read 32-bit values from addresses not divisible by 4. The set field of the (now really) packed record is not at an aligned address, and the RTS set routines do word access.
I see the following possible solutions:
Always align sets in packed records. This would break your binary files again.
Do it only on platforms with alignment requirements. This would increase the binary file incompatibilty between platforms. They're now not fully compatible due to endianness, but such a change would add another important issue which would not be easy to work around (i.e., it would be almost impossible to use such binary files in a platform-independent way).
Change the RTS set routines to byte accesses. That's easy to do (and has been discussed here some months ago), but would decrease the efficiency.
Let the RTS set routines check (on each invocation) if access is aligned. If not (and the platform requires it), use special code (like for packed arrays); otherwise use the faster word access.
Mixed approach:
- Do some of this work at compile time - since at compile time from record structure can be determined whether unaligned access can happen. This means that
one has two versions of RTS set routines - one (faster) for align-safe access and other, with checks deferred to runtime
If set is packed accidentaly at 32-bit word boundary, it's safe to do a compile time check - and it's programmers responsability to organize data efficiently.
(You will probably remember that I liked two versions of code even before, when we discussed runtime range checks).
Mirsad
-- This message has been made up using recycled ideas and language constructs. No plant or animal has been injured in process of making this message.