home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #30 / NN_1992_30.iso / spool / comp / arch / 11776 < prev    next >
Encoding:
Text File  |  1992-12-21  |  1.5 KB  |  36 lines
  1. Newsgroups: comp.arch
  2. Path: sparky!uunet!europa.asd.contel.com!emory!cs.utk.edu!willis1.cis.uab.edu!hyatt
  3. From: hyatt@cis.uab.edu (Robert Hyatt)
  4. Subject: Re: RISC assemblers question
  5. Message-ID: <1992Dec18.221947.8589@cis.uab.edu>
  6. Organization: University of Alabama at Birmingham
  7. References: <Dec.17.10.16.36.1992.17493@cadenza.rutgers.edu> <75756@apple.apple.COM>
  8. Date: Fri, 18 Dec 1992 22:19:47 GMT
  9. Lines: 25
  10.  
  11. In article <75756@apple.apple.COM> tim@Apple.COM (Tim Olson) writes:
  12. >In article <Dec.17.10.16.36.1992.17493@cadenza.rutgers.edu> masticol@cadenza.rutgers.edu (Steve Masticola) writes:
  13. >
  14. >|I've met a couple of people who have attempted to write assemblers for
  15. >|RISC machines, who say that it's a difficult job. Can someone give me
  16. >|an inkling as to why?
  17. >
  18. >From my experience, it's just the opposite.  RISC processors tend to
  19. >have a few simple instruction formats, fixed fields, etc.  Also, with
  20. >the limited number of addressing modes in RISC processors, parsing
  21. >becomes almost trivial.
  22. >
  23.  
  24.  
  25. The problem is that the assembler writer apparently never knows when his
  26. job is finished.....  :^)  He/she keeps writing, handling more special
  27. cases, etc.  The final product IS a difficult project.  However, I would
  28. prefer a simple assembler, not one that tries to "think" for me.  An 
  29. example is the one from Cray Research.  It doesn't "get in the way" of
  30. my bad (or good) coding practices.
  31.  
  32.  
  33. -- 
  34. !Robert Hyatt                    Computer and Information Sciences   !
  35. !hyatt@cis.uab.edu               University of Alabama at Birmingham !
  36.