home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / sys / amiga / programm / 17459 < prev    next >
Encoding:
Internet Message Format  |  1992-12-17  |  2.7 KB
  1. Xref: sparky comp.sys.amiga.programmer:17459 comp.sys.amiga.hardware:21679
  2. Path: sparky!uunet!noc.near.net!bigboote.WPI.EDU!nntp!ahansfor
  3. From: ahansfor@bigwpi.wpi.edu (Andrew L. Hansford)
  4. Newsgroups: comp.sys.amiga.programmer,comp.sys.amiga.hardware
  5. Subject: Re: CISC and RISC
  6. Date: 17 Dec 92 00:07:06
  7. Organization: Worcester Polytechnic Institute, Worcester, MA 01609-2280
  8. Lines: 47
  9. Message-ID: <AHANSFOR.92Dec17000706@bigwpi.wpi.edu>
  10. References: <70436@cup.portal.com> <amipb.04wr@amipb.gna.org> <37844@cbmvax.commodore.com>
  11.     <Bz8FD1.Dxt@ns1.nodak.edu> <1992Dec14.155039.7747@ugle.unit.no>
  12.     <BzAxFw.Is6@dcs.ed.ac.uk> <BzBtx4.DLE@gpu.utcs.utoronto.ca>
  13. NNTP-Posting-Host: bigwpi.wpi.edu
  14. In-reply-to: engb@gpu.utcs.utoronto.ca's message of 16 Dec 92 00:41:27 GMT
  15.  
  16. >>>>> On 16 Dec 92 00:41:27 GMT, engb@gpu.utcs.utoronto.ca (Ben Eng) said:
  17.  
  18. > It may be easier to make op.sys.-software on a CISC processor.
  19.  
  20. engb> I consider that to be an incorrect statement.  The operating
  21. engb> system is almost completely written in a language such as C or
  22. engb> C++, just like most other applications.  If the compiler handles
  23. engb> the translation well, where is the difficulty in generating code
  24. engb> for RISC processors?  I don't remember seeing volumes of
  25. engb> articles, or hearing many complaints from RISC OS implementors
  26. engb> about how difficult it is to generate code for RISC as opposed
  27. engb> to CISC.
  28.  
  29. I a paper titled "The Interaction of Architecture and Operating System
  30. Design" (Anderson,Levy,Bershad,Lazowska, Dept. of Computer Science and
  31. Engineering, University of Washington,) the authors discuss how
  32. current trends in OS and CPU designs are working in opposite
  33. directions.
  34.  
  35. OS performance has not had the speedup of most applications. (The OS
  36. is not a typical application.)  Some of the issues mentioned: 
  37.  
  38. 1) Code that was formerly in microcode now must be written in software.
  39.    Fine is done correctly, but sub-optimal code will probably exist.
  40.  
  41. 2) Code size of basic system functions.
  42.  
  43. 3) Time to do a context switch (very hairy on a processor with
  44. register windows).
  45.  
  46. 4) Interrupt handling - Many RISC machines do not have specific
  47. exceptions (ie tell you what instruction caused an exception or tell
  48. what the address that caused a page fault ).  And many do not have
  49. vector tables.  This can also effect how user applications trap into
  50. the kernel.
  51.  
  52. 5) saving and restoring state on a page fault - Restarting an
  53. instruction and restoring the pipeline to its previous state (or near
  54. to it) can be very time consuming. (Of course pipelined CISC has the
  55. same problem)
  56.  
  57. All in all OS still run more quickly on the RISC machines, but some of
  58. the "keep it simple" philosophy has made programming the chip more
  59. difficult in areas that require assembly language.
  60.  
  61. -- Andrew Hansford
  62.    ahansfor@wpi.wpi.edu
  63.