By: vonk (vonk.delete@this.sun.com), August 3, 2022 12:22 am
Room: Moderated Discussions
Mark Roulo (nothanks.delete@this.xxx.com) on August 2, 2022 6:48 pm wrote:
> I'll be interested to see what you find, but my (non-rigorous!) belief is that the most important thing for an
> ISA is to avoid a number of screwups. For ISAs intended for high performance implementations these include
>
>
> There are probably a few more, but once you've done this I think the actual IMPLEMENTATION starts to dominate.
I have one to add to your list: Never expose micro-architectural design choices in your ISA. The branch delay slot in early RISC/MIPS/SPARC being a prime example. You'll have to keep dealing with that behavior in future implementations which may take a whole different approach, and it'll be a pain.
> I'll be interested to see what you find, but my (non-rigorous!) belief is that the most important thing for an
> ISA is to avoid a number of screwups. For ISAs intended for high performance implementations these include
>
- Register windows. These mostly seem to be a bad idea.
- Stack or memory based architecture (you really want registers)
- Instruction encoding that makes parallel decode difficult (e.g. 680x0). Fixed
> length is one way to make parallel decode straightforward, but being able to easily/rapidly
> determine the length of a given instruction seems to be sufficient - Instructions with many indirect memory accesses
>
>
>
>
>
>
> There are probably a few more, but once you've done this I think the actual IMPLEMENTATION starts to dominate.
I have one to add to your list: Never expose micro-architectural design choices in your ISA. The branch delay slot in early RISC/MIPS/SPARC being a prime example. You'll have to keep dealing with that behavior in future implementations which may take a whole different approach, and it'll be a pain.