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

schwab at suse dot de wrote:
> ------- Additional Comments From schwab at suse dot de  2004-11-03 23:44 -------
> Even the 68020 should already show slight improvement when using 4 byte 
> aligment due to the 32 bit data bus (the 68000/010 only have a 16 bit data 
> bus). 
>  
> Adding an aligned attribute to the _Atomic_int type doesn't help for automatic 
> variables as gcc limits the alignment to STACK_BOUNDARY.  But it will work for 
> static variables. 
>  
> About the ABI change you are of course safe if everything is using the changed 
> aligment (including the interface to the RTEMS kernel). 
> 

That is certainly an option for RTEMS but I am still not sure since I
believe this is a problem across more targets.  At least, m68k-elf and 
m68k-coff have the same issue and I am willing to argue that this
could show up on a Linux or BSD system.

I started with the documentation for -m68060 which implies that
the intent is to not generate instructions which have to be emulated.
But here we are looking at a piece of manually written code that
violates that assumpion since m68060 does not also imply tighter
alignment.

`-m68060'
      Generate output for a 68060.  This is the default when the
      compiler is configured for 68060-based systems.

      This option inhibits the use of 68020 and 68881/68882 instructions
      that have to be emulated by software on the 68060.  Use this
      option if your 68060 does not have code to emulate those
      instructions.

There is a m68020-60 option which allows the use of emulated
instructions.  So GCC claims to be making a distinctions.

And Grrrr... I just found in the MC68060 Programmer's Guide
that the unaligned CAS instructions aren't in the emulation
package for the 68060.

So this is broken whether or not you are using the emulation package.
It just isn't there on the 68060.

Can _Atomic_word actually be a byte? Does CAS.B work?

--joel


-- 


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

Reply via email to