home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!cs.utexas.edu!sun-barr!male.EBay.Sun.COM!exodus.Eng.Sun.COM!not-and!nand
- From: nand@not-and.Eng.Sun.COM (Nand Mulchandani)
- Newsgroups: comp.arch
- Subject: Re: RISC assemblers question
- Date: 18 Dec 1992 03:26:09 GMT
- Organization: Sun Microsystems, Inc.
- Lines: 34
- Distribution: world
- Message-ID: <lj2h6hINNikj@exodus.Eng.Sun.COM>
- References: <1992Dec17.173930.3235@meiko.com>
- Reply-To: nand@not-and.Eng.Sun.COM
- NNTP-Posting-Host: not-and
-
- masticol@cadenza.rutgers.edu (Steve Masticola) writes:
- : Hi,
- :
- : I've met a couple of people who have attempted to write assemblers for
- : RISC machines, who say that it's a difficult job. Can someone give me
- : an inkling as to why?
- :
- : I'm not saying that it isn't; the reason just isn't obvious to me
- : right now.
- :
- : Thanks,
- : - Steve (masticol@cs.rutgers.edu).
-
- A couple of things make it a *little* harder :
-
- 1) Branches with delay slots (you have to be able to represent them and
- deal with them).
- 2) In general, chip workarounds are done in the assembler, and this code
- is just yuckier to deal with
- 3) branches have limited scope (on SPARC, you get only 22 bits in the branch
- instruction). It is reasonable to leave a check in the assembler to detect
- branches to targets that are larger than the displacement will allow.
- 4) Code to check architectural correctness (try doing something illegal
- with the SPARC assembler - if it sqawks, then someone had to write the code
- to do the check). This is very important, because the machine will not always
- execute "arbitrary assembly language".
-
- There may be others, these are the only ones that come to mind right now.
-
- Cheers.
-
- - Nand
-
-
-