Comment by tredre3 | Hacker News Reader

Comment by tredre3 | Hacker News Reader

I worked on SuperH3/4 compilers back in the day.

One thing I remember was how good Hitachi's documentation is! It was clear and concise and any quirk was well explained. The pseudo-code they used to describe each instruction was also good, C-like to the point that I was able to copy-paste the snippets with minor changes to write an emulator.

However the architecture itself was a bit annoying to work with because of the small opcodes. Doing something as simple as loading a 32bit immediate to a register ended up being 7-9 instructions. More realistically the compiler would put the values in LTORG and we'd load them from there in 1 or 2 instructions. Relative jumps were also an issue for the same reasons. It also inherited the infamous delay slots where half the instructions are illegal and the other half is quirky so we just NOPed them but I know that smarter compilers do useful work there.

That being said I do admire the elegance of how they fitted their 100 instructions with 16/24 registers in a 16bit opcode, it's a beautiful application of engineering trade-offs :).

Have you seen how terrible SH code generation is? At least code compiled in 2005-2009. Unnecessary moves:

mov r0, r3 <-result from a subroutine

mov r3, @r4

mov @r4, r3

do something with value.

And many many more examples like this. Wasting cycles and space.

Yes, I do Dreamcast homebrew, and even with GCC 12.2, the compiler does such stupid, stupid things.

The SH has addressing modes for postincrement reads and predecrement writes, so something like

  var = *ptr++;

can be compiled down to a single instruction. But GCC almost always does something moronic. I've seen it generate code equivalent to:

  ptr++; tmp = ptr; tmp -= 16; var = tmp[15];

Insane.

Older versions of GCC (3.x) are generally much better at low level instruction selection, but newer versions are better at big-picture stuff like optimizing across function calls, so speed-wise, across a whole program, they aren't too dissimilar. Newer versions are still worth it for the feature set (better warnings, modern standards like C23/C++23, etc).

>> engineering trade-offs

Its not obvious what they trade off and got in return.

The article mentions that ARM licensed SuperH patents for their Thumb instruction set, and ARM did that for improved code density, so that seems to be what they got in return.

If you read through all 10 parts of the series, Raymond later mentions that it might look like a lot of code but instructions are half as big as other RISC contemporaries so it's better than it looks.

> instructions are half as big as other RISC contemporaries

That's a bit of a gimmick, tbh. Yes you can just about make it work if you have a really barebones insn set, as the early SuperH chips had. (You do need to start from a 2-register insn format of course.) But modern chips - even quite small chips nowadays - benefit from having more than that, so you're left with a really limited niche.

(I do think that the calculus changes if you have a strictly Harvard architecture chip/core, since these might be able to afford a "weird" instruction length. A core with, e.g. 20-bit or 24-bit fixed-length instructions designed along the same lines gains some much needed space for ISA extension.)

Reply on news.ycombinator.com