Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!yale!hsdndev!spdcc!ima!dirtydog!suitti From: suitti@ima.isc.com (Stephen Uitti) Newsgroups: comp.arch Subject: Re: RISCizing a CISC processor Message-ID: <1990Dec07.215604.29896@dirtydog.ima.isc.com> Date: 7 Dec 90 21:56:04 GMT References: <9012070105.AA02416@hcrlgw.crl.hitachi.co.jp> <1990Dec7.061826.28241@ux1.cso.uiuc.edu> <2339.275f7e44@iccgcc.decnet.ab.com> <1990Dec7.192707.10303@ux1.cso.uiuc.edu> Sender: news@dirtydog.ima.isc.com (NEWS ADMIN) Reply-To: suitti@ima.isc.com (Stephen Uitti) Organization: Interactive Systems, Cambridge, MA 02138-5302 Lines: 62 > What about instruction decode? RICS machines tend to have > fixed-format instructions that are easy to decode. (i.e. all The 386 & 68K are easy compared to a VAX. However, this sort of thing has been done for VAXen. > RISCs tend to have alignment > restrictions to a greater extent than CISCs. This is one of those things that must be dealt with. It can be done with traps - slowly. If you have unaligned references on a VAX 780, it is slower. Most people won't notice. Even relatively dumb pcc based C compilers attempted to make this unlikely. Some examples: static data is aligned, malloc returns aligned pointers. It still happens. The uVAX II, for example, does not implement the entire VAX set. There wasn't enough room, or something. The OS gets traps, and emulates the instructions. This has been done for floating point for years on all sorts of machines. > If the translator is imperfect (likely) then end-users won't want > to try it and probably couldn't (no sources to work from). This isn't a new thing. For example, Interactive's UNIX for the 386 emulates a 387 if one isn't there. Think a 387 is simple to emulate? ...easy to test? Intel doesn't always get the chips right the first time either. In fact, people who produce CPUs often get it wrong for awhile on their 2nd & on generations. That doesn't mean it can't or won't be done. And it doesn't mean it isn't worth doing. Actually, there are lots of timing problems in systems that get shipped. Sometimes customers find them. I've had software that ran properly have a couple non-repeatable glitches here and there after only three or four months of CPU time on what most of us would call very reliable machines. It happens. The other thing you can do is design your hardware so that most of the instructions (that are used) get run in a cycle, and the CPU does the less used stuff in microcode. It can still be on chip. You won't get the advantage of not using a big chip. You won't get the high speed instruction decode you'd get from RISC. These are solvable - larger chips, more chips, multiple decoders, etc. It can be OK to spend money on the CPU for systems if the CPU costs are low relative to the systems. On the other end of the spectrum, people still produce weird 4 bit systems that are hard to program, that don't have lots of RAM or ROM, that don't have expandability for RAM, ROM, I/O, or anything, just because the CPU chip is the system, and thousands or millions of them are to be produced. Everybody wants a faster system. Yet, there are lots of people whose primary programing vehicle is the shell... Stephen. suitti@ima.isc.com "We Americans want peace, and it is now evident that we must be prepared to demand it. For other peoples have wanted peace, and the peace they received was the peace of death." - the Most Rev. Francis J. Spellman, Archbishop of New York. 22 September, 1940