You could use a method similar to what has been used in m68k-amigaos C code to allocate long word aligned structures like FileInfoBlock from the stack:
@salass00 interesting idea - many thanks. For the first time I heard about constructor attribute. Looks nice, on weekend I will test.
Before you post this advice, I had in plan more dirty solution, something like: double Tarray[3]; double *pT,*pT1; pT= (double*)((long)(Tarray +1) - (long)(Tarray % 8)); pT1= pT+1;
Thx!
Edited by sailor on 2025/1/24 20:47:35 Edited by sailor on 2025/1/24 20:48:45 Edited by sailor on 2025/1/24 20:53:08 Edited by sailor on 2025/1/24 20:53:41
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
You could use a method similar to what has been used in m68k-amigaos C code to allocate long word aligned structures like FileInfoBlock from the stack:
I could be wrong but I don't think definining a pointer to a multi-dimensional array will work. In my experience multi-dimensional arrays in C are quite limited in how they can be used so I almost never use them in my code.
What should work however is something like (not quite as elegant):
@flash native SPE version of gcc libraries will be fine, of course. NXP had CodeWarrior IDE for SPE in past, but there were other compiller than gcc. It will solve workarounds with float / double calls.
But global variable alignment error is probably directly in gcc - linking script error like salass00 said.
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
-1 ?? char does NOT add a extra 0\, its not a string, so why do you want on less char? a string is a class, not a array for chars.
This is code from salass00 hint (see above). If I understand it correctly, "-1" is here to allocate only needed memory, not more: allign_buffer should have size at least ( nr.of variables + 1 )*( sizeof(variable)) - we need to shift variable to correct aligned address. If variable is not correctly alligned, is shifted of certain nr. of bytes ( i.e. maximally of var.size -1 ). Shifting of var.size have no sense, because it have the same alignment like original. Thus we allocated one byte less. Of course, if var.size is less then 8 bytes, this shape should be corrected a little. Quote:
GCC should automatilcy allign data, and you can use compiler options for it, "packed".
Yes, in theory. Please, see post nr.53. Aligning not works always for global variables. In that case I need 8-byte alignment for experiments with SPE SIMD unit. And this workaround helps me much. This error is connected to gcc linker script ( see comment )
AmigaOS3: Amiga 1200 AmigaOS4: Micro A1-C, AmigaOne XE, Pegasos II, Sam440ep, Sam440ep-flex, AmigaOne X1000 MorphOS: Efika 5200b, Pegasos I, Pegasos II, Powerbook, Mac Mini, iMac, Powermac Quad
its not a string, so why do you want on less char?
I'm not allocating one byte less, I'm allocating sizeof(double)-1 bytes more than needed. This is to ensure that a double (8-byte) aligned address of the required size can always be found within the aligned buffer no matter what the alignment of the array itself is.
Quote:
GCC should automatilcy allign data, and you can use compiler options for it, "packed".
It should but it doesn't.
Using my own compiled test code as example:
While the .data section itself is 16-byte aligned to the start of the executable file:
Section Headers:
[Nr] Name Type Addr Off Size
[ 6] .ctors PROGBITS 01011094 001094 000008 00 WA 0 0 4
[ 7] .dtors PROGBITS 0101109c 00109c 000008 00 WA 0 0 4
[ 8] .data PROGBITS 010110b0 0010b0 000010 00 WA 0 0 16
it is preceeded in the segment by .ctors and .dtors sections which are only 4-byte aligned (see above):
The result is that when elf.library loads the entire segment 32-byte aligned the .data section gets loaded into it at offset 10b0-1094=1c which is only 4-byte aligned.
GCC should automatilcy allign data, and you can use compiler options for it, "packed".
"packed" (__attribute__, #pragma, etc.) can only be used to reduce alignment, for example from 4 bytes integer default on PPC to 2 bytes (for compatibility to m68k, as used in most exec, etc. includes), but not to increase alignment.
@salass00 Quote:
The result is that when elf.library loads the entire segment 32-byte aligned the .data section gets loaded into it at offset 10b0-1094=1c which is only 4-byte aligned.
Still sounds like a linker script bug to me, missing or wrong align for .ctors/.dtors, not a bug in gcc, binutils (ld) nor elf.library. However the last time I worked on it in the AmigaOS 4.x ports was IIRC gcc 2.95.x/binutils 2.14.x versions, i.e. about 20 years ago...
So someone could try to compile and assemble SPE code with native GCC 4 and link objects with GCC 11. If problem rely on linker, and if it's a text file it could be easily fixed with a diff between GCC4 and GCC11 linker cfg text files