home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!portal!cup.portal.com!Tony-Preston
- From: Tony-Preston@cup.portal.com (ANTHONY FRANCIS PRESTON)
- Newsgroups: comp.sys.amiga.hardware
- Subject: Re: CISC and RISC
- Message-ID: <71896@cup.portal.com>
- Date: Thu, 17 Dec 92 07:18:52 PST
- Organization: The Portal System (TM)
- References: <70436@cup.portal.com> <amipb.04wr@amipb.gna.org>
- <37844@cbmvax.commodore.com><Bz8FD1.Dxt@ns1.nodak.edu>
- <1992Dec14.155039.7747@ugle.unit.no><BzAxFw.Is6@dcs.ed.ac.uk>
- <BzBtx4.DLE@gpu.utcs.utoronto.ca><71809@cup.portal.com>
- <1992Dec16.185008.8536@bmerh85.bnr.ca>
- Lines: 60
-
- |ANTHONY> Believe the voice of experience, give me a CICS processor any
- |ANTHONY> time! Besides, the 68040 has a 1.3 instruction/clock
- |ANTHONY> execution rate, that is nearly as fast as most RISC machines.
- |
- |But can the 68040 be scaled up to 66-100 Mhz? The RISC designs can.
- Maybe not, but it could be! There is little in a RISC that makes
- it be able to run at faster rates that cannot be done to CICS designs.
- |
- |ANTHONY> So what if the instructions execute three times faster if you
- |ANTHONY> need almost twice as many! In a SPARC, I had 3 instructions
- |ANTHONY> to load data from memory(two to build the address, one to
- |ANTHONY> load relative to the address in a register), It sure executed
- |ANTHONY> those instructions fast...
- |
- |But... Ideally you only have to build the address once, leave it in a
- |register, and access all/most of your data (certainly any localized
- |data) relative to that register. i.e. you rarely pay that 2
- |instruction overhead.
- I have practical experience with the SPARC, you do have to do it. The
- problem is that people believe that you have unlimited registeYHW rs
- available, you don't. The same code moved to a SPARC was about 40%
- larger than the 68020 code. It was all in assembly. If you look at
- the register windows and other things in most RISC designs, you have
- twice the registers in most cases(compared to the 680x0 family).
- |
- |I will grant that:
- | add.l dx,dy on the m680X0 (2 bytes)
- |is shorter than:
- | add dx,dy,dz on a RISC type (4 bytes, usually).
- the problem is more this. I have two data items in memory, I want to
- add and store them in a third. On the SPARC, i do somthing like:
-
- Load Item 1(3 instructions)
- Load Item 2(3 instructions)
- add item 1 to item 2(1 instructions)
- Store item 3(3 instructions)
-
- Now with the 680x0, we have:
- Load item 1(1 instruction)
- Add from memory(1 instruction)
- Store to memory( 1 instruction)
-
- So I have a RISC machine with a 80 Mhz clock that takes 125 ns to do the
- operation(aproximately), and my 40 mhz 68040 which takes about 50 ns to
- to the same operation. Why do I need a "faster" RISC processor when my
- programs are 3 times bigger. Ok, this is a roughly contrived example, but
- based on REAL WORLD programming experience, this is close to the general
- case. If you program in C, the compiler will probably do a better job
- of generating code(in fact, I learned several tricks from the C compiler
- machine code listings on the SPARC). The bottom line is it costs more
- to program the RISC machine. Programmer costs along with memory and in
- cases like my example, actual speed of execution! The good things about
- RISC are more registers, not unlimited registers, and faster easier to
- decode instructions. Well, those advantages are offset as CISC processors
- grab the good features while ignoring the bad.
- I fully expect that 5 years from now, the distinction will be alot smaller
- between RISC and CISC than it is today! One of the reasons for more register
- s in the CPU was because memory speeds could not keep up with the CPU, the
- CISC processors today have CACHE instead of registers, a better solution in
- my opinion.
-