hi,

Thanks for the "brief" historical note. It's a nice reminder. I'd
confounded the spl/mfpr sed script,  the br/cvec, and
"device-driver"/c2 -i. Thanks for pointing  that out.


And a not-so-brief follow-up on the "cpu" config proposal, since I'm
told I can do what I want with the existing tools, but I still don't
see how I can,  quite...


>>I can see fairly arbitrary rules being "reasonable", depending on how
>>rich a set of -m flags the compiler provides ...

>You can get this now with `makeoptions'.  Simply
>change an appropriate rule in Makefile.i386 from, e.g.,
>
>	CC=	gcc2 ${WARN} ${DEBUG}
>
>to:
>
>	CC=	gcc2 ${WARN} ${DEBUG} ${CCMFLAGS}
>
>and then add:
>
>	makeoptions	CCMFLAGS="-m486"

Yes, one could.  I think "makeoptions" is great for selecting the
CPU model to *schedule*  for, but I  don't like using it to select
the level of insns actually *generated*.   See below..


>Of course, you may have to remember to change the -mXXX when
>you change `options CYRIX686' or whatever.

Uhuh.  That's what worries me about this approach: It seems too
fragile.  I'd rather specify each supported CPU model in one place,
and have config do two things with it: configure any CPU-dependent
source files into the kernel, as "device" would; and also put some
``well-known'' token into the Makefile, so that Makefile back-end
rules can compute an arppropriate set of -m options.

The advantage I see in inventing a new keyword is that CPU support is
then done in only one place.  If the set of CPU models a kernel
supports is specified in two places -- one for the relevant code to
include for those CPUs, and another for the target insn set -- people
*will* get them inconsistent, produce kernels that don't boot, and
then blame the toolset for letting them get it wrong.


If that's not clear, the example I was thinking of was for mips-based
machines, where one might configure a kernel for:

	* MIPS-I (r2000) machines
	* MIPS-III (r4000) machines

The return-from-exception handlers, TLB bits, cache manipulation,
and previous/current mode bits are quite different on MIPS-I and
MIPS-III. These reside in separate locore files.  I haven't tried
a "device" entry for this but it seems like it'd work.

But I'd also like kernels to be automagically compiled with the
``best'' compiler options for the configured CPUs.  I'd like the
compiler to emit r4000 insns (squashed branch, etc) for the
machine/model-independent code if, and only if, the kernel config
doesn't include MIPS-I.  (the model-dependent code needs to be
special-cased: the mips-III locore source always needs to emit
mips-III insns, even if mips-I support is configured).

I can kludge up a set of rules to do something reasonable in the
Makefile, given the set of CPUs for which support was configured. the
part that I think is missing is how to pull out the the set of CPUs
specified in the config file (via "device", or something else) from
the config file, and pass that into the Makefile in a way that's
visible to (e.g.) make's if-then-else.

If one is willing to accept the risks of configuring inconsistent CPU
"device" support and compiler instruction-subset CPU support, and to
put the burden of choosing the correct insn set to the user, then no
extensions to config are necessary.  I think replies saying ``you can
do what you want already'' are ambiguous. They might be implicitly
assuming the limitations of the current config.  Or they might be
replies from people who've carefully considered their own risk/benefit
tradeoff from a new keyword and decided it's not worth it.

I can't tell one from the other, so far, and I think it makes a
difference :).  Or perhaps the distinction between selecting a CPU
model for which to schedule code to, and the insn level to emit code
for (they're not always subsets, insns get deleted as well as added,
and gcc does *NOT*, in general, take the intersection of multiple -mcpu
flags!) are being confounded.