Hyperion Entertainment Message Boards

Hi,

I'm wondering if GCC in the latest SDK 53.24 has been compiled with -mstrict-align (to force the alignment of floating point types), or if it still required to add that switch to every makefile when compiling stuff for OS4?

Reference thread on amigaworld: http://amigaworld.net/modules/newbb/vie ... 8&forum=15

Thanks and regards,
Varthall

@Varthall

Why do you think you need it? Unless packing is explicitly overridden using "#pragma pack(x)" directives or "__attribute__((packed))" any float or double values should already be correctly aligned according to their size by the compiler. FWIW if packing is overridden and it's done for a reason other than simply saving a few bytes of memory then simply adding "-mstrict-align" will probably not be enough to fix the code.

From what I have read, the GCC included in the previous SDK (4.2.4, build 20090118) didn't correctly align floats for Sam440's cpu (it needs them to be 8 bytes aligned instead of 4 bytes like on other PPC cpus). This might cause programs compiled with it to crash with an alignment exception. A ticket has been opened on adtools' page, and it's still in the "open" status:

http://sourceforge.net/p/adtools/bugs/14/

The GCC included in the latest SDK seems to be the same version as the old one, so I guess that the bug is still present.

Varthall

Varthall wrote:From what I have read, the GCC included in the previous SDK (4.2.4, build 20090118) didn't correctly align floats for Sam440's cpu (it needs them to be 8 bytes aligned instead of 4 bytes like on other PPC cpus).

I don't know where you got this information but it is wrong.

salass00 wrote:

Varthall wrote:From what I have read, the GCC included in the previous SDK (4.2.4, build 20090118) didn't correctly align floats for Sam440's cpu (it needs them to be 8 bytes aligned instead of 4 bytes like on other PPC cpus).

I don't know where you got this information but it is wrong.

This is where I read about this problem:

http://amigaworld.net/modules/newbb/vie ... =Go#495826

http://www.amigans.net/modules/xforum/v ... mpost35873

If the switch is not (and never was) required, I'd post a message in both threads to inform that the switch is actually redundant.

Varthall

Varthall wrote:
I don't know where you got this information but it is wrong.
This is where I read about this problem:

http://amigaworld.net/modules/newbb/vie ... =Go#495826

http://www.amigans.net/modules/xforum/v ... mpost35873

If the switch is not (and never was) required, I'd post a message in both threads to inform that the switch is actually redundant.

Varthall

There was also extensive discussion of the SAM440 alignment issue at UtilityBase. Unfortunately, UtilityBase is unavailable. Since this was a SAM440 issue, maybe you could get a more definitive answer from ACube. It's their hardware and they should know the answer to your question.

@Varthall

Why not read the links you posted yourself. They say exactly what I stated before that there is only a problem if you override the default packing on structures containing any kind of floating point values by using f.e. "#pragma pack()" directive.

The -mstrict-align option just forces the floating point values to be aligned correctly in such structures by adding extra pad bytes in spite of what has been requested by the programmer which can likely end up causing other problems in the code if the code in question is not fixed properly.

I found the conversation in those links confusing myself. You seem to be saying that NOT using the #pragma pack() directive and NOT using -MSTRICT-ALIGN will resullt in correct allignment in structures containing floating point variables. Does that apply to the example given in the second link:

Example:
{
UBYTE8 ...;
ULONG ...;
float ...;
}

xenic wrote:I found the conversation in those links confusing myself. You seem to be saying that NOT using the #pragma pack() directive and NOT using -MSTRICT-ALIGN will resullt in correct allignment in structures containing floating point variables. Does that apply to the example given in the second link:

Example:
{
UBYTE8 ...;
ULONG ...;
float ...;
}

In your example 3 pad bytes would be added after the UBYTE value to ensure optimal alignment of the ULONG value. This is BTW incompatible with how m68k-amigaos compilers work which is why "#pragma pack(2)" is needed for any structures that should be compatible with m68k code.

Using "#pragma pack(2)" the compiler only ever ensures 16-bit alignment which would mean that only one pad byte would be added in the above example.