Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!glacier!oliveb!intelca!clif From: clif@intelca.UUCP (Clif Purkiser) Newsgroups: net.arch Subject: Re: Re: Addressing modes Message-ID: <221@intelca.UUCP> Date: Wed, 26-Feb-86 23:57:58 EST Article-I.D.: intelca.221 Posted: Wed Feb 26 23:57:58 1986 Date-Received: Sat, 1-Mar-86 01:37:14 EST References: <946@garfield.UUCP> <1417@sdcsvax.UUCP> <6777@boring.UUCP> <1433@gitpyr.UUCP> <169@ubc-cs.UUCP> <1982@peora.UUCP> <1476@lanl.ARP27 Feb 86 04:57:58 GMT Organization: Intel, Santa Clara, Ca. Lines: 108 > In article <1982@peora.UUCP> jer@peora.UUCP (J. Eric Roskos) writes: > >> As far as I'm concerned, the test for RISCness should be: given any piece > >> of source code, is there only one reasonable code sequence which can be > >> output by the compiler? > > > >How is that a test for "RISCness"? Following the above scheme, you could, > >for example, have a machine that directly (and optimally) interpreted some > >concise representation of the source code... but that's exactly what people > >are calling a CISC machine, and are claiming is bad... > > That's just the problem. The designers of CISC machines think that they > are making the compiler writer's job easier by supplying opcodes to > perform high level semantics. Unfortunately, NO ONE has yet succeeded > in developing an instruction set which can 'directly (and optimally)' > interpret the semantics of the source code. What usually happens is > that the 'high level' instruction is not as efficient as a sequence or > loop of simpler instructions - or it is only efficient for a subset of > its possible uses. ( As an example, consider the famous case of the VAX > instruction for evaluating polynomials. It was never as fast as a loop > of simpler code to do the same job and it was horribly inefficient in > the case where the compiler could detect a large number of zero > coefficients.) As a result, compilers must be VERY complex to generate > good code on CISC machines. > > At best, the CISC machines provide some instructions which are generally > useful as well as lots of instructions which are seldom or never used > (consider all the wierd addressing modes of modern vaxen - which most > compilers never generate). The idea of RISC is to keep these instructions > which are generally useful, and make them as fast as possible by > eliminating all the seldom used instructions. A useful side effect of > RISC archetecture is that it permits compiler writers to implement high > level semantics with simple 'codes skeletons' since there is usually only > one efficient sequence of code which reflects the required meaning. > > J. Giles > Los Alamos The problem with RISC when taken to it is logically conclusion is you get rid of a lot of useful instructions and very useful addressing modes. The RISC machine I designed for my Computer Architecture course (taught by Mr. RISC Dave Patterson ) had 24 instructions and two addressing modes it didn't even have a multiple. While I was very happy at the time that I didn't have to try to right microcode for a lot of complex instructions! (The previous class had to implement the Z8000 with TTL SSI and MSI parts) My machine sure took a long time to do useful work. Needless to say my RISC computer was a toy compared to real RISC machines. J. Giles point is well taken that compiler writers have not yet figured out a way of taking advantage of the numerous addressing modes and instructions offered by CISC machines such as 86, Z8K, 68K or 32K families. I would even concede that you can still have a RISC machine that takes more than one clock to complete an instruction. This allows an important instruction such as multiple to be included in the instruction set. At first glance many CISC instructions seem useless (some probably are) but on closer glance that generally have quite a few uses. Take for example my favorite CISC machine (you guessed it) the 80386. I am sure no good RISC designer would include such obscure instructions as Ascii Adjust for Addition, Subtraction, AAA,AAS etc. or XLAT (Table Look-up Translation). Yet they all have their uses. The Ascii Adjust instruction are used by COBOL (yes people still use it) compilers and spreadsheet designers because COBOL uses BCD and these instruction speed this process up. Likewise, XLAT can be used for converting ASCII to EBCDIC in 5 clocks. One disagreement I have with the RISC proponents is the theory that everyone writes in a HLL. It seems that despite years of trying to force everyone to write in HLL languages there will always be a few assembly language programers. Because no matter how much performance Semicoducter and Computer companies give programmers they always want their programs to run faster. So these CISC instructions while not useful to compiler writers are useful to assembly language jocks. I also think that many of the addressing modes on CISC machines result in higher performance than the simpler RISC addressing modes. For example take long x, a[10], i; x = a[i]; This probably compiles into these RISC instructions assuming x, a, and i are in register R1,R2, and R3 respectively. ShiftL R4, R3, #2 Add R4, R4, R2 Load R1, [R4] This is a single 4 clock instruction on the 80386 vs 3 clocks for the RISC chip. However, the RISC chip has had to fetch 3 instructions vs one for the CISC processor. So unless the RISC chip has a large on-chip cache it will be slower. I guess my main point is that a RISC designer in the search to simplify the chips complexity may easily throw out obscure instructions which are useful to certain applications. Or they may eliminate generally useful addressing modes. I think that the good thing about the RISC philosphy is that it will reduce the tendency of designers to add new instructions or addressing modes just because they look whizzy or Brand X has them. If a complex way of doing something is slower than a simple way don't put it in. -- Clif Purkiser, Intel, Santa Clara, Ca. HIGH PERFORMANCE MICROPROCESSORS {pur-ee,hplabs,amd,scgvaxd,dual,idi,omsvax}!intelca!clif {standard disclaimer about how these views are mine and may not reflect the views of Intel, my boss , or USNET goes here. }