[Bug libstdc++/17627] M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

["joel at oarcorp dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From joel at oarcorp dot com  2004-11-03 23:25 -------
Subject: Re:  M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

cjohns at cybertec dot com dot au wrote:
> ------- Additional Comments From cjohns at cybertec dot com dot au  2004-11-03 23:05 -------
> Does this mean the instruction in question (cas) in atomicity.h cannot be used
> on the 68060 if the stack can be aligned to a 2 byte boundary ?

Not if the memory to be swapped is on the stack.  The memory could be in 
global memory and be properly aligned.

Grrr... I forgot you can do this with GCC:

typedef unsigned int _Atomic_word __attribute__ ((aligned (4)));

Wouldn't changing the definition for the m68k to the above fix this?

> Would a stack aligned this way cause a slow down if the call/ret address being
> pushed and popped is not aligned to a 32bit boundary ?

I suspect it would but don't know the MC68060 enough to state that 
authoritatively.

> I do not full understand the ABI issues hence my next question. RTEMS +
> application is built as a single executable, typically all with the same tool
> set, so does an ABI issue exist in our case ?

If you can find something in a FreeScale document showing improved
performance for aligned accesses on the MC68060, that would tell me
that for RTEMS, we want mc68060 to imply stricter alignment.  I would
bet that others would as well if a performance increase is obtained.

--joel




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17627