6 ms·

I used to work in automotive software, where the SH-2A was a popular choice for engine controller units, particularly in Japan. It was the first CPU I encounte

I used to work in automotive software, where the SH-2A was a popular choice for engine controller units, particularly in Japan. It was the first CPU I encountered that uses branch delay slots [1], meaning that the instruction immediately following a branch instruction is always executed, even when the branch is taken. That took a bit of getting used to, although I understand it's quite common on RISC architectures. The SH-4 was most notably used in the Sega Dreamcast. [1]: https://en.wikipedia.org/wiki/Delay_slot https://en.wikipedia.org/wiki/Delay_slot

mananaysiempre 5y ago
Branch delay slots are pretty common on old-school RISC archs such as MIPS and SPARC, but AFAIU when those designs were faced with microarchitectural evolution the initial simplicity turned out not to be worth it. Neither PowerPC, Alpha, ARM (if you consider it a RISC), nor RISC-V have them. (A similar thing happened with ARM’s two-words-ahead PC.) It’s another matter if your microarchitecture is your architecture: apparently modern DSPs still have them, although I don’t know where you could learn about those, what with most designs being secret.
- wvenable 5y ago
  With deeper pipelines, architectures with branch delay slots had to start emulating them for compatibility -- turning the performance/design advantage into a disadvantage.
audunw 5y ago
OpenRISC, which I worked on in an embedded application, also has branch delay slots. I thought it looked like a clever idea. Then I wondered why RISC-V so quickly took over OpenRISC as the darling ISA of the open source community. What I read then is that branch delay slots was one of the problems, as it creates problems when designing fast modern (superscalar) CPUs. That’s been my impression of RISC-V in general. Whenever someone thinks another ISA does it better, there seems to be a very well thought-out reason for RISC-V’s decision, when you take into consideration that it’s built to scale from the smallest microcontroller to the biggest CPU. The RISC-V standards is also evolving, if something isn’t there it can also be that it’s planned for future revisions. There’s a proposed revision coming up that would make RISC-V beat ARM in code density across the board, on real world embedded code.
- Narishma 5y ago
  Do you have a link to the proposal?
- thesz 5y ago
  Alpha AXP get rid of branch delay slot from the very start, precisely because they planned it to be architecture that is viable for next 20-25 years. And I think that RISC-V is right on repeating that design decision. ;) It also looks like Alpha was introduced a bit earlier than SuperH and that makes me wonder why they still wanted branch delay slot. It is nothing but trouble across the board (tools, hardware design, etc) for couple of percents of execution speed. Which can easily be achieved just by using register bypass and that bypass logic will cost less and bring more, effectively reducing pipeline length by one stage.

mananaysiempre 5y ago

Branch delay slots are pretty common on old-school RISC archs such as MIPS and SPARC, but AFAIU when those designs were faced with microarchitectural evolution the initial simplicity turned out not to be worth it. Neither PowerPC, Alpha, ARM (if you consider it a RISC), nor RISC-V have them. (A similar thing happened with ARM’s two-words-ahead PC.) It’s another matter if your microarchitecture is your architecture: apparently modern DSPs still have them, although I don’t know where you could learn about those, what with most designs being secret.

wvenable 5y ago
With deeper pipelines, architectures with branch delay slots had to start emulating them for compatibility -- turning the performance/design advantage into a disadvantage.

audunw 5y ago

OpenRISC, which I worked on in an embedded application, also has branch delay slots. I thought it looked like a clever idea. Then I wondered why RISC-V so quickly took over OpenRISC as the darling ISA of the open source community. What I read then is that branch delay slots was one of the problems, as it creates problems when designing fast modern (superscalar) CPUs. That’s been my impression of RISC-V in general. Whenever someone thinks another ISA does it better, there seems to be a very well thought-out reason for RISC-V’s decision, when you take into consideration that it’s built to scale from the smallest microcontroller to the biggest CPU. The RISC-V standards is also evolving, if something isn’t there it can also be that it’s planned for future revisions. There’s a proposed revision coming up that would make RISC-V beat ARM in code density across the board, on real world embedded code.

Narishma 5y ago
Do you have a link to the proposal?
thesz 5y ago
Alpha AXP get rid of branch delay slot from the very start, precisely because they planned it to be architecture that is viable for next 20-25 years. And I think that RISC-V is right on repeating that design decision. ;) It also looks like Alpha was introduced a bit earlier than SuperH and that makes me wonder why they still wanted branch delay slot. It is nothing but trouble across the board (tools, hardware design, etc) for couple of percents of execution speed. Which can easily be achieved just by using register bypass and that bypass logic will cost less and bring more, effectively reducing pipeline length by one stage.