Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site peora.UUCP Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!houxm!vax135!petsd!peora!jer From: jer@peora.UUCP (J. Eric Roskos) Newsgroups: net.arch Subject: Re: RISC/CISC - IBM mainframes Message-ID: <1062@peora.UUCP> Date: Thu, 13-Jun-85 08:36:49 EDT Article-I.D.: peora.1062 Posted: Thu Jun 13 08:36:49 1985 Date-Received: Fri, 14-Jun-85 04:42:32 EDT References: <1452@ecsvax.UUCP> Organization: Perkin-Elmer SDC, Orlando, Fl. Lines: 46 You're right, I think (i.e., I'll take sides temporarily in this one). The problem with CISC machines has tended to be that the instructions were not developed in cooperation with the compiler writers. Thus you have (in the classic example) the IBM EDIT instruction, which was supposed to be good for COBOL, but unfortunately doesn't work in a way that is usable by COBOL compilers. For a starting point, most compilers incorporate run-time-libraries [however you define that term] which perform functions not supported by the host machine. An easy example of this is floating point arithmetic. Machines without floating point instructions invoke run-time libraries; those that have the instructions use them instead, with a performance improvement (if the instructions are correctly implemented, of course). In the case of the greatest floating point performance improvement, this is done by having special hardware (e.g., floating point coprocessors) to perform the operations, but how it's implemented is not really the issue here; the issue is whether the "complex" instruction "Floating Divide", for example, is "better" than a sequence of "reduced" instructions that do the same thing. One of the problems with arguing for RISC or CISC is that they are just high-level manifestations of underlying design approaches. It's my opinion, personally, that a machine with writable control store which can be dynamically loaded tends to give the advantages of both machines; because you can microprogram routines that are executed often enough to gain a performance improvement, while having the compact object code and reduction in the number of primary memory instruction fetches (and just simpler macroinstruction-level object code) which you get from the CISC machines. A reasonable approach to producing CISC machines, then, would be to have the compiler writers design the instruction set; and to have the instruction set be changeable for different languages. This could be extended by having the instruction set be further changeable by the individual user, or automatically by a program that analyzes instruction usage and moves frequently-used instructions into microcode (vertical migration). (These are not new ideas, of course; a lot of research is currently going on in these areas, but is not as well-known as the RISC research, apparently.) -- Full-Name: J. Eric Roskos UUCP: ..!{decvax,ucbvax,ihnp4}!vax135!petsd!peora!jer US Mail: MS 795; Perkin-Elmer SDC; 2486 Sand Lake Road, Orlando, FL 32809-7642 "Gnyx gb gur fhayvtug, pnyyre..."