Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!acorn!moncam!paul From: paul@moncam.co.uk (Paul Hudson) Newsgroups: comp.arch Subject: Re: Compiling - RISC vs. CISC Message-ID: Date: 12 Jul 89 10:31:43 GMT References: <2190@oakhill.UUCP> <13980@lanl.gov> <2199@oakhill.UUCP> Sender: paul@moncam.co.uk Organization: Monotype ADG, Cambridge, UK. Lines: 85 In-reply-to: davet@oakhill.UUCP's message of 11 Jul 89 10:24:06 GMT In article <2199@oakhill.UUCP> davet@oakhill.UUCP (David Trissel) writes: In article <13980@lanl.gov> jlg@lanl.gov (Jim Giles) writes: >> What about the required pairing of registers for double wide operations >> such as floating-point or shifting? >In what way does a machine which requires register pairing qualify as >a RISC? The point was that RISC architectures DO require the pairing. Can you name any that don't? ARM. (Acorn Risc Machine) last time I looked ... >If an instruction requires 2 operands, they should be allowed >to be any two general purpose registers. This is not what was being discussed. But it is relevant to the complexity of the compiler. >Furthermore, you are assuming >that floating point is larger than other intrinsic types. Well, unless you limit yourself to only single-precision, floating-point IS larger than other instrinsic types. [ omitted ] >So, this issue _does_ have a bearing on the complexity of the compiler. >If you are not willing to provide the sophisticated compilers required >to adequately use a machine, you have wasted money (read: design effort, >chip space, etc.) on the hardware. Nope, no bearing on the compiler. There is no gun being pointed at the compiler writer forcing her to utilize all the available instructions. Your assumption that most of the instructions have to be used "to adequately use a machine" is simply incorrect. But what's the point in having those instructions, then? Why not use all that silicon real-estate for something else? >All the optimizations required on a RISC are also required on a CISC. Wrong. 68K compilers don't have to worry about register pairing. 68K compilers don't have to worry about branch delayed slot filling, setting up segment registers for data addressability, etc. Neither does the compilers for the ARM. (except addressing literals, and that wasn't difficult). >CISC just adds more complexity to the mix. I showed otherwise in that RISC has it's own set of headaches. I don't see much difference in the total amount of work involved for either RISC or CISC. >Now, clearly 5 instructions may take longer than the 1 in your 68K example. Actually RISCs only require 2 or 3 instructions to do the work of the one in that example. >All this may mean that 5 instructions on a RISC may be _faster_ than one on a CISC. Not when using the latest CISCs. I think all this shows that it depends on the particular examples of CISC or RISC rather than being generic. I would argue that most RISCs are more regular in their instruction sets than most CISCs, and that this does make compilers significantly easier. My experience in this is limited to writing a replacement code generator for pcc for the Acorn Risc Machine. The result had only peephole optimisation and couldn't compete with an fully-optimizing compiler, but still gave quite good results. More importantly, it was working quite quickly - here the regularilty of register use and instructions was a big win. -- Paul Hudson MAIL: Monotype ADG, Science Park, Cambridge, CB4 4FQ, UK. PHONE: +44 (223) 420018 EMAIL: paul@moncam.co.uk, ;" FAX: +44 (223) 420911 ...!ukc!acorn!moncam!paul `"";";" "/dev/null full: please empty the bit bucket"