Bug 17627

My copy of the 68060 manual says that CAS is unimplemented _only_ for 
misaligned EA. 

Agreed. The section C.2.2.3 of the user manual states this is the case when it
details the emulation software.

So is the alignment issue in the stack based __result and (if yes) then __temp ?

If this is true could this be an RTEMS stack initialisation issue ? That is, I
would expect GCC to keep the stack aligned for the 68060.

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-09-23 10:20 -------
> Agreed. The section C.2.2.3 of the user manual states this is the case when it
> details the emulation software.
> 
> So is the alignment issue in the stack based __result and (if yes) then __temp ?
> 
> If this is true could this be an RTEMS stack initialisation issue ? That is, I
> would expect GCC to keep the stack aligned for the 68060.

Each RTEMS task stack is supposed to start out at least 4 byte aligned.
The heap only returns things that way. :)

Chris could you check the starting stack pointer in the TCB and the
current SP just before this code?

Will close unless update.

-benjamin

I emailed Chris privately.  The stack is properly aligned.  But his target is
not setup at the moment and he would have to build a special toolset without his
workwound/fix in place.  He won't be able to do this in the few days.

This shouldn't be closed.  Without target hardware, is there way it can be checked?

Has any attempt been made to even desk check the code in question?

Subject: Bug 17627

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	bkoz@gcc.gnu.org	2004-11-02 23:56:57

Modified files:
	libstdc++-v3   : ChangeLog 
	libstdc++-v3/src: debug.cc 

Log message:
	2004-11-02  Benjamin Kosnik  <bkoz@redhat.com>
	Lothar Werzinger  <lothar@xcerla.com>
	
	PR libstdc++/17627
	* src/debug.cc: Include concurrence, use mutexes.
	(_Safe_iterator_base::_M_attach): Here.
	(_Safe_iterator_base::_M_detach): Here.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/ChangeLog.diff?cvsroot=gcc&r1=1.2744&r2=1.2745
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libstdc++-v3/src/debug.cc.diff?cvsroot=gcc&r1=1.8&r2=1.9

Joel, you might want to talk to the m68k maintainers. 

Take your pick:
m68hc11 port            Stephane Carrez         stcarrez@nerim.fr
m68k port (?)           Jeff Law                law@redhat.com
m68k-motorola-sysv port Philippe De Muyter      phdm@macqel.be

Since you are the rtems maintainer, I'm expecting you to be on top of fixing
this, since it's currently seen as a m68k-rtems bug.

This bug hasn't been framed in a clear manner, IMHO. There's no test case, no
patch file. If it's a generic m68k problem with 68060 and libstdc++ atomicity,
it should be marked as such (and not rtems-specific.) If this has nothing to do
with libstdc++, but instead has something to do with gcc or rtems, well, the
category on this bug should reflect this.

Hope this helps.

-benjamin

Subject: Re:  M68060 fails with libstdc++-v3/config/cpu/m68k/atomicity.h

bkoz at gcc dot gnu dot org wrote:
> ------- Additional Comments From bkoz at gcc dot gnu dot org  2004-11-03 00:12 -------
> 
> Joel, you might want to talk to the m68k maintainers. 
> 
> Take your pick:
> m68hc11 port            Stephane Carrez         stcarrez@nerim.fr
> m68k port (?)           Jeff Law                law@redhat.com
> m68k-motorola-sysv port Philippe De Muyter      phdm@macqel.be
> 
> Since you are the rtems maintainer, I'm expecting you to be on top of fixing
> this, since it's currently seen as a m68k-rtems bug.
> 
> This bug hasn't been framed in a clear manner, IMHO. There's no test case, no
> patch file. If it's a generic m68k problem with 68060 and libstdc++ atomicity,
> it should be marked as such (and not rtems-specific.) If this has nothing to do
> with libstdc++, but instead has something to do with gcc or rtems, well, the
> category on this bug should reflect this.
> 
> Hope this helps.

It does and just reiterates what shuold have been done when it was 
reported.  Chris is going to try to put together a test case.

What we are concerned about is that it is more than likely a generic
problem.  Very few problems are RTEMS specific at this level.  Chris
believes that a 16-bit variable may be allocated on the stack and
this would result in it being misaligned.  This is likely the issue.
The MC68060 can't do misaligned accesses for the instruction in 
question.  On a MC68060 without software emulation of missing 
instructions, then you get a fault.

So the concern is that this is a generic m680x0 issue with
letting the stack get misaligned and it just gets caught in
this one very complex C++ scenario.

Don't close it yet and give Chris a chance to give a test case.

--joel

On the m68k the biggest alignment has traditionally only been 2 bytes 
(inherited from the Sun compiler, AFAIK), and it's only overridden on NetBSD 
(and previously on some configurations that are removed now) or when using 
-malign-int.  So unless you change that (which of course changes the ABI) 
you'll continue to get unaligned long words somewhere. 

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 22:25 -------
> On the m68k the biggest alignment has traditionally only been 2 bytes 
> (inherited from the Sun compiler, AFAIK), and it's only overridden on NetBSD 
> (and previously on some configurations that are removed now) or when using 
> -malign-int.  So unless you change that (which of course changes the ABI) 
> you'll continue to get unaligned long words somewhere. 

Then I think the m68060 breaks that rule by not supporting a number of
m68040 integer and FP instructions.  They provide software to handle
traps for unimplemented instructions but for performance reasons it is
best to avoid generating them in the first place.  This is similar to
how the 68040's reduced FP capabilities relative to the 68881/2 was handled.

http://www.freescale.com/files/product/doc/MC68060AR_D.pdf

(hand-typed .. sorry) describes the differences between a 68040 and 
68040.  On page 5, it specifically mentions that the CAS and CAS2
"Unlike the MC68040, the MC68060 supports the CAS instruction with 
misaligned operands, and all CAS2 variants, only via software emulation."

Table 7 on page 11, gives a full list of unimplemented integer
instructions.

Off the cuff, one possible solution is that _Atomic_word does not
have a required alignment.  I know it is possible to force alignment
on a variable. Can the same be done with a type?  T

Or is the solution to do as Andreas suggests and turn on the -malign-int
option by default on the MC68060?

I wouldn't think that making the alignment 4 bytes on the MC68060 target
would be a huge impact since those should be relatively large memory
targets board configurations anyway.

--joel

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 ?

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 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 ?

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

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). 

Chris Johns <cjohns@cybertec.com.au> asked me:

>Is the Coldfire aligned to a 2 byte boundary or a 4 byte boundary ?

The Colfire operates the same as the x86 in that the cache/bus unit will
automagically handle unaligned data as multiple aligned accesses for smaller
data sizes (i.e. byte-short-byte) to the bus/cache to access a long on a
0bxxxxxx11 address without a software trap.

Chris also asks in comment #11:

>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 ?

On the ColdFire core there will be a *measurable* performance hit if the stack
is not kept long aligned since the interface from the ColdFire core to the cache
unit will have to prevent accesses that can straddle alignment boundaries, so an
access that is entirely within a cache line boundary, but is unaligned(for the
size of the access) will still be broken up into seperate aligned accesses to
the cache.  The 16 bit instruction alignement performance penalty is mitigated
by the instruction pre-fetch unit performing 32-bit aligned accesses to the
cache/bus unit.

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

My copy of the 68060 user manual says that the MC68060ISP does contain an 
emulation for unaligned CAS. 

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-04 15:12 -------
> My copy of the 68060 user manual says that the MC68060ISP does contain an 
> emulation for unaligned CAS. 
> 


OK.  Likely yours is newer and they fixed that.  So this is back to 
being primarily an embedded systems issues.

I still wonder if since the -m68060 flag says it avoids emulated
instructions, if that switch should imply stricter alignment while
the -m68020-60 should not.

What about that?

--joel

You can't just increase the alignment as that would break the ABI. 

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-04 16:53 -------
> You can't just increase the alignment as that would break the ABI. 

Are we stuck with requiring the 68060 ISP package even when
-m68060 is specified and it says no emulated instructions are
used?

GCC ALMOST meets the no ISP requirement with the -m68060 argument
but can't do it completely without breaking the ABI.  Grrr..

I hate to suggest this but is it possible to add a -m68060-noisp
option to increase the alignment and avoid the rest of the issues.

I don't want to change the code generation rules/ABI for the
-m68060 argument, so I think we are stuck clarifying the documentation
to include that it maintains ABI compatability and in doing so
may generate code which violates strict alignment requirements.  To
support these edge conditions you must have the ISP.

Any other thoughts?

--joel

Any news on this?

No change. I have arranged to get the MVME172 card back for an afternoon later
this week (11-Feb-2005). I will have a look then.

No feedback in more than 6 months.