home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.amiga.programmer:17537 comp.sys.amiga.hardware:21777
- Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!zaphod.ncsa.uiuc.edu!robm
- From: robm@zaphod.ncsa.uiuc.edu (Rob McCool)
- Subject: Re: CISC and RISC
- X-Newsreader: Tin 1.1 PL5
- References: <vac133m.724654821@nella8.cc.monash.edu.au>
- Message-ID: <BzGtLG.MCH@news.cso.uiuc.edu>
- Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
- Organization: The Organization of Disorganization
- Date: Fri, 18 Dec 1992 17:22:26 GMT
- Lines: 21
-
- Richard Jones (vac133m@nella8.cc.monash.edu.au) wrote:
- : Yes, CISC _is_ easier to program in most cases because the instructions are
- : generalized. As for memory writes.. if your chip is doing this then I suggest
- : you change manufacturers..
-
- This is hardware interlocking, and there are different approaches used to
- the problem. The problem is memory latency; we all know memory is slow
- and it takes 2 cycles to execute a load. The problem is when someone does
- a load, and then in the next instruction does something to the just-loaded
- data.
-
- The SPARC has interlocking which will insert no-ops into the pipeline if
- there is an instruction which attempts to reference data that is not there
- yet. The MIPS decided to leave out hardware interlocking, and depend on the
- software to do proper instruction scheduling to gain speed, and so if
- you reference data that has not been loaded yet you will get garbage.
-
- --
- Rob McCool, NCSA STG System Administrator
- robm@ncsa.uiuc.edu r-mccool@uiuc.edu robm@imsa.edu
- It was working ten minutes ago, I swear...
-