Jeff Smith <jeffs@geocast.com> writes:
> "Chris G. Demetriou" wrote:
> > > What does SiByte have?  EEtimes didn't say :-)
> > 
> > I could tell you, but I'd have to kill you.  I'm sure you know how it
> > goes.  8-)
> 
> 32KB 4 way I and D caches.  You can repeat what's
> in the press releases :-)

Oh, heh, I don't think I actually bothered to compare what was in the
press releases vs. the EEtimes article.  (The one bit that I recall
about those two things, if i recall correctly, is that there was even
more information in the actual EPF presentation, that would really
make people salivate. 8-)


> You should be fairly motivated then to help make multi way cache
> support more efficient than it is now.  The sibyte processor would
> take it pretty hard the way it is now unless the cache ops are more
> efficent than other implementations.

Yes, so, I come at this wearing several hats.  One is as a SiByte
employee, another is as a NetBSD hacker.

Wearing the latter hat, i'd like the code to be as flexible as
necessary to support a wide variety of MIPS-family processors, and as
efficient as is reasonable given the former goal.

Wearing the former hat, i'd like the code to actually be capable of
functioning properly on our chips, and then as efficient as possible.

Reading the code, with an eye towards understanding and using the code
is what brought me to ask these questions to begin with.  (I must
admit, i was and still am a bit dumbfounded by things.)


Unfortunately, I don't think _any_ of those goals is actually met by
the current code.  8-)

Another "unfortunately" is that I don't have time in my budget to
actually sit down and give the MI mips code the whacking that it seems
to need.  (If i were to do so, pmap, TLB replacement, and cache
handling would probably be where i'd start.)

The final "unfortunately" is that even if i were to give the MI code a
significant drubbing, I don't have adequate hardware to test on...




chris