It has a number of other nice strengths too, e.g. tagged-operand
operations that let you open-code Lisp arithmetic efficiently, doing
the typecheck in parallel with the actual operation. And see below
about save/restore.
> I think we compared the pentium pro architecture with the
> sparc/v8 (or v7, whichever it was at the time). The results were
> of course scalability. The sparc could context switch within one
> or two clock cycles while the pentium pro took approximately 20-50.
> I can see how that'd be an advantage, however, it would slowly go
> away as you scaled to more and more processes. The sparc we looked
> at had 8 context frames.
A couple of things to be aware of:
- interrupts push to the next context frame (aka register window). So
each process needs two, one to handle interrupts and one to run the
process.
- the usual call-return sequence is to do a SAVE right after the call
(allocating and using a new window) and a RESTORE right before
the return. This means that processes that are actively calling and
returning will use register windows like they're going out of style,
which they are.
- this call-return sequence is faster than the usual
push-everything-on-a-stack-in-RAM sequence for parameter passing --
another nice feature of the SPARC.
- Register windows are not memory mappings. I don't know how long
changing your memory mapping takes, but I suspect it is much more than
two clock cycles.
Beware! I know this from reading the Ross Technologies UltraSPARC
databook, not from actual experience. Gordon Irlam is probably the
person on this list most knowledgeable about SPARCs.
-- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> According to my medieval text in the seventh century a finalizer raised a dead object named Gorth who infected every computer in Cappidocia ending Roman rule in the region. -- Charles Fiterman on gclist@iecc.com