On Mon, Dec 21, 2009 at 09:57:21PM +0100, Jens Axboe wrote:
> On Tue, Dec 22 2009, Paul Mundt wrote:
> > On Tue, Dec 22, 2009 at 05:47:46AM +0900, Nobuhiro Iwamatsu wrote:
> > > +#define nop __asm__ __volatile__ ("nop": : :"memory")
> > > +#define read_barrier() __asm__ __volatile__ (" " : : : "memory")
> > > +#define write_barrier() __asm__ __volatile__ (" " : : : "memory")
> >
> > This is true for SH-4, but not for SH-4A, which wants a synco for these.
> > See how the kernel does it.
> >
> > The sooner we stop pretending like SH-4A and SH-4 are the same thing the
> > sooner we stop introducing subtle bugs all over the place.
>
> Does sh-a4 support the synco instruction, or will it sigill?
>
SH-4A supports synco, SH-4 does not. SH-4A is based on the SH-4, but has
a lot of new instructions and so forth. Folks like to treat them the same
so as to keep the same ABI, but there are a lot of architectural
differences that are ideally not just glossed over. We have been bitten
by these in the past.
Linux reports different uname values for all of SH-4, SH-4A, and
SH4AL-DSP largely for these reasons, and gcc also has different
preprocessor tokens for each. In this case, an __SH4A__ test can be done
for synco with the above definitions sufficing for all other variants.
Where this silliness started was with FPU-less variants of SH-4 defining
__SH3__ because the gcc folks decided that an SH-4 without FPU
instructions was "close enough" to the SH-3 ISA, which while generally
true at the time, also ignored the fact that they have completely
different caches -- SH-4/SH-4A/SH4AL-DSP parts end up having to do
I-cache block invalidations from the libc, while SH-3 does not. SH-4 and
SH-4A preprocessor tokens on the other hand are sensibly abstracted, so
there is no reason to pretend like everything is SH-4.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
