Subject: Re: modernizing config
To: Charles M. Hannum <mycroft@mit.edu>
From: Jonathan Stone <jonathan@dsg.stanford.edu>
List: tech-kern
Date: 08/12/1996 18:37:50
>Jonathan Stone <jonathan@DSG.Stanford.EDU> writes:

>> 
>> While changes for config are up for grabs, can we add a section
>> to support configuring for different levels, or models, of a target
>> platform?  Old config used to support this with the "cpu" keyword.
>> Most ports are now supporting this with ad-hoc options. 

>What would such a line actually *do*?
I hadn't thought it out completely...

One thing such a line would do is cause config to set a corresponding
Make flag in the Makefile it builds, so that the Makefile can compute
a set of appropriate compiler flags, given the CPUs that the kernel
was configured for.  (I haven't specified how to compute Makefile
variable names from options, that shoulnd't be too hard.) I like the
idea of using the same option to select "locore" support options
and selecting compiler options for a specific CPU.


I can see fairly arbitrary rules being "reasonable", depending on how
rich a set of -m flags the compiler provides. I think ports, or
compilers of ports, might want to influence both the level of CPU for
which insns are actually emitted (e.g., don't emit 486 or Pentium
insns), and the CPU-level for which code should be scheduled -- and
make different choices for the two.

In the specific case I'm thinking of, selecting MIPS-III (r4000) level support
would select both compilation of MIPS-III locore code, _and_,
if and only if MIPS-I is not also selected, enable generation of
native mips-III level instructions.

I can see something very similar being useful for Sparcs.

>  How would you propose getting
>it to change the compiler options, for example?  You can already do
>this, to some extent, with make's fancy substitution hacks.

For a first pass I'd prefer to try coding the rules in Makefile
if-statements, again assuming the relevant options are visible
as Make or environment variables.  I don't want to try doing
substitution on ${IDENT} to pick out a single variable: "Ick".
And maybe I'm misunderstandign following Jason's proposal, but
isn't there a thought much of ${IDENT} might disappear soon, too?