Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!pasteur!ernie.Berkeley.EDU!hunt
From: hunt@ernie.Berkeley.EDU (Jim Hunt)
Newsgroups: comp.arch
Subject: multi-threaded SPARC question
Message-ID: <19439@pasteur.Berkeley.EDU>
Date: 10 Nov 89 22:56:50 GMT
Sender: news@pasteur.Berkeley.EDU
Reply-To: hunt@ernie.Berkeley.EDU.UUCP (Jim Hunt)
Distribution: na
Organization: University of California, Berkeley
Lines: 27

It seems possible that a SPARC chip could be used as 8 loaded
contexts, instead of 8 windows.  The compiler could generate code
for a 16 register machine, and do it's own register allocation a la
mips, and never use the push and pop calls.  But the problem is
that the chip responds to traps and interrupts by doing a push (or
pop?) and writing some state in the next window, then calling the
handler.  So, can the handlers be rewritten to deal with this???
In such a way as to have a system with 8 loaded contexts and an
OS that can swap them HEP style at high speed?  Yes, register
usage would be poor, you might have to give a up couple that the HW
trap overwrites, and the int/trap handlers would be gross, but if
your system has 200 cycle message delay, then context (really
thread) switch time is very critical.

I have fully convinced myself that it MIGHT be possible, and
would like to hear from anyone who has gone beyond that and
actually done it, or even attempted to really nail down the
issues involved.  The system would be drastically changed, but if
it is doable, our 32 proc. butterfly would be a lot nicer.

Please, results only, I already BELIEVE it might be possible.
I am most interested in "Yeah, I did it, here it is" or else "No,
I tried, and it can't be done because";  Hopefully the former.

jim hunt@ernie.Berkeley.EDU	H&H Enterprises (1 employee)
These ARE the bosses opinions, I AM the * boss!!!
grad UCB, MS EE/CS, May 90, resume on request.