On Tue, 9 Oct 2007, Franck Bui-Huu wrote:
> > What would be the gain for the kernel from using "-march=4ksd" rather
> > than "-march=mips32r2"?
> It actually results in a kernel image ~30kbytes smaller for the former
> case. It has been discussed sometimes ago on this list. I'm sorry but
> I don't know why...
Perhaps the pipeline description for the 4KSd CPU is different from the
default for the MIPS32r2 ISA. Barring a study of GCC sources, if that
really troubles you, you could build the same version of the kernel with
3. "-march=mips32r2 -mtune=4ksd"
and compare the results. I expect the results of #2 and #3 to be the same
and it would just back up my suggestion about keeping CPU-specific
optimisations separate from the CPU selection. Please also note that our
optimisation model is for speed (-O2) rather than size (-Os), so if
"-mtune=4ksd" yields smaller code than "-mtune=mips32r2", it just means it
is safe for this CPU to shrink code where appropriate without losing
performance. One obvious place for such a choice is the use of the
hardware multiplier vs shifts and additions where one multiplicand is a
> > What if you want to run a single kernel image regardless of the CPU
> > installed in the system. Rebuilding the kernel (or having to keep a large
> > collection of binaries) just because you want to swap the CPU does not
> > seem like a terribly attractive idea. Some systems come with their CPU(s)
> > on a daughtercard (each), you know...
> ok, I wasn't aware about this. You could have started by this point ;)
Well, daughtercards for CPUs are so common for me -- the vast majority of
MIPS-based systems I use have them -- that I have assumed, obviously
incorrectly, that you see a benefit from such a rewrite of the TLB
exception handlers which is large enough to justify the inconvenience of
limiting the kernel to a given CPU card.
> So now I think the right direction is to stick with tlbex.c and
> make it smaller like Ralf did.
That is certainly a good idea.