@smarkugs
Quote:
But a lame question
The problem lies where ?
The alignment issue is a pretty fat one, and CPU specific: "it consists of three separate but related issues: data alignment, data structure padding, and packing" (c) wiki. The issue happens not only on PPC CPUs, but also on ARM (so Pandora, Pyra): The ARM itself can access unaligned data, but coprocessor (so Floats and SIMD (they have Neon, like our Altivec/SPE/etc) ) cannot.
By default, PPC architecture (at least how it has written in the “green book”) does not allow _ANY_ unaligned access. Mean that 16 bit must be 16 bit aligned, 32 bit must be 32 bit aligned, etc. However, this rule may be relaxed by CPUs that actually implement the architecture. So, since most CPUs can do it, the compilers happily generate code that is doing unaligned accesses. In most cases, this works, sometimes it leads to slower access, but the _correct_ response would be an alignment exception (as we have on x5000).
So if we take into account Wipeout : it is a bug in the game, just, as often happens, it's on AmigaOS4 we find most of real bugs which just hide on other cpus/oses/drivers/kerneles/etc. So far to be seen what kind of alignment bug wipeout had: unaligned memory access, unaligned padding, unaligned packing or just mixture of them.
Also, some alignment issues still can be fixed by compiler by providing cpu options as well as -mno-strict-align / -mstrict-align (they on System V.4 and embedded PowerPC systems do not (do) assume that unaligned memory references are handled by the system). But again, it can deal with some alignment issues, but not with others (like accessing to unaligned floats).
An easy and good test case for checking unaligned floats (for example, as one of alignment issues) is:
#include <stdio.h>
int main(int argc, char **argv)
{
// Declare a 16-byte buffer, it will be aligned on 16 bytes
printf("A buffer contains the same 4-byte pattern at index 1 (unaligned) and 8 (aligned)\n");
char buffer[16] = {0, 60, 127, 113, 58, 5, 6, 7, 60, 127, 113, 58, 12, 13, 14, 15};
volatile char * ptr;
// Read the reference pattern at an aligned address (buffer + 8)
ptr = buffer + 8;
printf("Read the reference pattern at an aligned address (buffer + 8) (addr = %p)\n", ptr);
printf("float = %f\n", *(float *)ptr);
// Read the same pattern at an unaligned address (buffer + 1)
ptr = buffer + 1;
printf("Read the same pattern at an unaligned address (buffer + 1) (addr = %p)\n", ptr);
printf("float = %f\n", *(float *)ptr);
return 0;
}
This test case works on x1000, but didn't on x5000. And, it can be that X1000's PPC CPU do allow unaligned floating point access, for example, while X5000's one and Sam460's one didn't. But as i told before PPC cpus all should not allow unaligned access of any sort.
Back in times, when i port IrrlichtEngine to OS4, there were one loader in engine which do load MS3D meshes, which cause unalignment errors on x5000 for me. And so far, when i ask about issues with, the ppls in os4beta-list explain the things for me (the ones part of which i wrote above), and, Matthias (Corto), do fix it for me, that how the fix were looks like:
https://github.com/kas1e/Irrlicht/comm ... a3b6cc2ea571071a3edb1dcb8So as can be seen, it's all can't be fixed like by change some line, it should be proper aligned data in the memory, as well as padding , as well as packing. And as i say this is the bug in wipeout and should be fixed.
One may ask: why we have no this issues on Linux PPC and on MorphOS - they may have some software emulation of unalined access in kernels (but it means make things be slower, and to be seen on what CPU wipeout works on linux ppc and morphos to have a proper answer about)
At least, that how i understand it all.
Edited by kas1e on 2023/9/12 6:48:23
Edited by kas1e on 2023/9/12 6:59:30
Edited by kas1e on 2023/9/12 7:03:54
Edited by kas1e on 2023/9/12 7:28:16
Edited by kas1e on 2023/9/12 7:34:23