On Tue, Dec 22, 2009 at 06:20:41AM +0900, Paul Mundt wrote: > 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). > I should also clarify that for the purposes of this patch, the SH-5 has a totally different ABI, and therefore also a completely different set of syscall numbers. SH-5 is only exposed to userspace as sh64 however, so it can safely be ignored in the context of an sh-specific patch.
-- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
