Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!unmvax!pprg.unm.edu!hc!lanl!opus!ted From: ted@nmsu.edu (Ted Dunning) Newsgroups: comp.arch Subject: Re: Bandwidth and RISC vs. CISC Message-ID: Date: 3 May 89 16:35:34 GMT References: <38853@bbn.COM> <423@bnr-fos.UUCP> <288@ctycal.UUCP> <1262@l.cc.purdue.edu> <231@celit.UUCP> <10544@cit-vax.Caltech.Edu> <1827@ccncsu.ColoState.EDU> Sender: news@nmsu.edu Organization: NMSU Computer Science Lines: 24 In-reply-to: bullerj@handel.colostate.edu's message of 3 May 89 14:55:43 GMT In article <1827@ccncsu.ColoState.EDU> bullerj@handel.colostate.edu (Jon Buller) writes: In article <10544@cit-vax.Caltech.Edu> yair@tybalt.caltech.edu.UUCP (Yair Zadik) writes: >A couple of years ago there was an article in Byte about a >proposed design >which they called WISC for Writeable Instruction >Set Computer. The idea ... The only problem with this is that doing a context switch is nearly impossible. Imagine not only saving registers but having to swap out microcode and instructions too. ... GOLLY, do you think that maybe we could build some cool hardware that would keep track and only swap out the parts of the microcode that were different, or maybe even only swap in the parts that were new, and then why stop there. I mean, like, lets swap parts of the user program and data into and out of this fast control store. And let's make the backing store be main memory so it is easier to get to... isn't this leading right back to a normal risc with a cache that allows programs to share executable segments?