> No, this isn't another stupid message saying "My hyperSPARC won't work!".
> 
> Actually, I'm curious as to what, exactly, the problems are WRT hyperSPARC
> and _why_ it won't work.  Is it the hyperCACHE issue, or is it problems
> with the architecture itself?
> 
> And, of course, the dreaded question: "How long before this can/will be
> fixed?"
> 
> Inquiring minds want to know... :-)

Well, there are a bunch of problems. Most of them would be pretty easy to
solve in theory...

For example, handling of traps and asynchronous faults is most likely wrong,
since I wrote the handler from a manual that I later found out to be full
of misprints (and I didn't exactly understand the chip all that well at
the time...).

There is no cache support for the HS; again, this should not be hard to fix;
it is just a matter of finding out 
(1) how to enable it
(2) how to flush it
(3) how it aliases (it is a virtually-addressed cache; I'm guessing that
    the existing support for Sun4c virtual caches will "just work")

I also have no idea how the HS->mbus interface works (it may be similar
to the Supersparc, in which case it will "just work"), or how it handles
cache coherency with DVMA.

The big problem with fixing these problems is in getting them to coexist 
with support for other machines. Consider, for example, the handler for
an asynchronous memory fault trap. In assembler, within a trap window,
you have to (1) test the CPU type/model (2) jump to the appropriate piece
of code (3) read the appropriate registers, in the right order, with 
the right bits set in the MMU to avoid other faults (4) pass it up to a
CPU-specific C-level handler that knows how to interpret the stuff read
in in the assembly routine.

	"Ugh"

A lot of this, especially the cache support, would be much easier if 
the CPU type-information were centralized and there were a set of dispatch
functions to be used for things like "flush page in preparation for DVMA",
since these things are done differently on different CPUs.

As I've said before, I've got an old source tree that has this centralization
about half-done. Unfortunately, it is based on pre-1.2 source, and I just
haven't had the time to pull it up to 1.2-current to release it for other
people to play with (I really don't have time to work on such a major 
revamp of the code this year, with my thesis and all).

I'll try to get this source out to the world within two weeks, after the
Sigmetrics deadline and my midterms next week; maybe someone with a tad 
more time can play with it...if I don't, start sending me obnoxious email
until I get around to it :-)

--Aaron