> # 
> # It just seems gross to build a second trap table for each CPU rev, for
> # the sake of a single trap. But we certainly use different tables for 
> # Sun4/4c/4m.
> 
> So why not initialise the trap table for a "standard" (lowest rev) sun4m,
> and then fix only those which need fixing (keep an array which you
> then map in as necessary)?
> 
> ...or is that what you meant when you said "...that's what we do now"?

No, that's not what we do right now, since we don't support the HyperSparc,
etc. right now. 

The way to do this is probably to patch the trap table. It is just a real
pain in the ass to do, since the trap table (unlike the x86) is vectorized,
so you have to patch jump instructions and so forth. You also have to move
the CPU revision/model detection code to locore (i.e. in assembly) to have
the trap table correctly patched before moving up to C level. You then also
have to write separate copies of the memory fault handler for each machine
that does things differently (i.e. some CPUs you have to read a fault addr
before the status reg, and on others you have to read the status reg before
the address).

None of this is impossible, it is just annoying, and it would be nice
to get a general solution that cleans up the huge amounts of special-
cased code throughout the port. This way it would be much easier to
add support for currently unsupported hardware as people try it and 
find hardware bugs/inconsistencies.

Also, lest it seem otherwise, patching the trap table is not the only
problem with supporting the hypersparc! I just picked it out as an example
of the messiness needed to support the multiple CPUs. For example, the
Hypersparc doesn't have a coherent/physical Icache, so there needs to be
extra Icache flushing logic, etc., etc...

--Aaron

(P.S. sorry if I'm sounding pissed off...I'm fighting with a theory
problem set and I really *don't* *care* if the Gaussian integers
are or are not a Euclidean ring today!)