[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: Bug#561891: Please support sh4



On Mon, Dec 21, 2009 at 10:16:40PM +0100, Jens Axboe wrote:
> On Tue, Dec 22 2009, Paul Mundt wrote:
> > 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.
> 
> Thanks for the clarification, Paul. One last question... Will __SH4A__
> cover sh5 as well, or does it need a __SH5__?
> 
That will need an __SH5__. SH-4A got things like synco from the SH-5 ISA,
so in most of these cases a test for __SH4A__ or __SH5__ will do. This is
how the kernel does it today at least (although only the instruction
mnemonic is preserved, the actual encoding and instruction size are
completely different).


Reply to: