Guidelines for instruction set design?

"Richard O'Keefe" <ok@cs.otago.ac.nz>
Tue, 26 May 2009 15:16:28 +1200

          From comp.compilers

Related articles
[14 earlier articles]
Re: Guidelines for instruction set design? toby@telegraphics.com.au (toby) (2009-05-10)
Re: Guidelines for instruction set design? anton@mips.complang.tuwien.ac.at (2009-05-12)
Re: Guidelines for instruction set design? gneuner2@comcast.net (George Neuner) (2009-05-12)
Re: Guidelines for instruction set design? walter@bytecraft.com (Walter Banks) (2009-05-13)
Re: Guidelines for instruction set design? DrDiettrich1@aol.com (Hans-Peter Diettrich) (2009-05-13)
Re: Guidelines for instruction set design? cfc@shell01.TheWorld.com (Chris F Clark) (2009-05-18)
Guidelines for instruction set design? ok@cs.otago.ac.nz (Richard O'Keefe) (2009-05-26)
Re: Guidelines for instruction set design? gopi.onthemove@gmail.com (2009-06-03)
| List of all articles for this month |

From: "Richard O'Keefe" <ok@cs.otago.ac.nz>
Newsgroups: comp.compilers
Date: Tue, 26 May 2009 15:16:28 +1200
Organization: Compilers Central
Keywords: architecture, design, question
Posted-Date: 28 May 2009 17:37:07 EDT

John said:
          C should be pretty straightforward on anything
          with flat byte addressing and enough registers to handle stack
frames.
I'm looking at a machine that
          - has no addressing modes,
              just (mem, addr_reg) -> read
              and addr_reg -> write (result turns up in mem some time later)
          - has no ADD instruction, only subtraction
              (so I'm looking at handling base+offset as offset-base',
              i.e. keeping all pointers negated)
          - has no byte addressing: everything is 16 bits
          - uses segment registers to address 8MB of memory
          - that's one segment register for all loads and another
              for all stores, plus one in the DMA unit
          - has no shifts (use multiply)
          - you don't want to know about immediate values
          ...
The lack of byte addressing is the easiest issue to deal with:
just declare that bytes are 16 bits and char == short == int < long.
_Flat_ addressing is much more important than _byte_ addressing,
because you can't handle segments well without language changes.


So here's one general guideline: don't do _that_.
At least
          - base register + offset addressing (z/Series, ni System/360,
              gets by with 12 bit unsigned offsets, but it's a bit of a pain)
          - byte addressing (though as the Alpha showed, you don't _have_
              to have byte loads or stores, though as the Alpha later showed,
              if you don't have them you _do_ miss them)
          - getting a full width constant shouldn't be _too_ complicated
              (you _can_ load them from memory; System/360 again; something
              like the Transputer's way of extending immediates is nice)
          - remember that pointer difference requires division



Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.