Franck wrote:
2006/1/25, Kevin D. Kissell <kevink@xxxxxxxx>:
Franck wrote:
OK. So the patch I sent to you 3 months ago that adds support for
4ks[cd] cpu and smartmips extension is wrong. It added new
CONFIG_CPU_4KS[CD] macro whereas it must have used MIPS32_R[12] macros
like Kevin suggested...
Not really. As we discussed at the time, the 4KSc is a superset of
MIPS32 which includes some, but not all MIPS32R2 features (plus other
stuff), and the 4KSd is a strict superset of MIPS32R2. So some additional
information is required to express the desired support. I was just pointing
out, in the case of the SWAB optimizations, that there was no need to invent
yet another way of describing MIPS32R2.
Let's say that the 4KSC has "wsbh" instruction which is part of
MIPS32R2 instructrion set (I haven't checked it). The question is how
the 4KSC would use the SWAB optimizations since it doesn't define
CONFIG_CPU_MIPS32_R2 ? The 4KSC might not be the only one case...
The 4KSc happens not to have the MIPS32R2 WSBH (is that pronounced
"wasabi"? ;o) instruction, but it does have the MIPS32R2 ROTR, because
it's part of the SmartMIPS ASE. Our options here include:
* Say "to heck with it" and deny the 4KSc use of the ROTR, and stay
with a "#ifdef CONFIG_CPU_MIPS32R2" conditional.
* Define CONFIG_CPU_MIPS4KSC as an additional oddball CPU flag, and
make it "#if defined(CONFIG_CPU_MIPS32R2) || defined(CONFIG_CPU_MIPS4KSC)
* Have an ASE-support flag, CONFIG_CPU_SMARTMIPS, which would cover both
the 4KSc and 4KSd. In that case code using ROTR could be conditional on
#if defined(CPU_CONFIG_MIPS32R2) || defined(CONFIG_CPU_SMARTMIPS).
I personally think that the third option is the cleanest and most conceptually
correct, but I'm not the guy operationally responsible for maintaining
that code.
Regards,
Kevin K.
