A cool thing about Thumb/ARM, is that you can actually switch between the two instruction sets in your binary. You essentially dump your cache when this happens, but you can do it.
Well yeah, but “only runs ARM” is less surprising to me than “only runs Thumb”, especially on 64-bit where it’s essentially a different architecture altogether. Or maybe I’m just crabby because I wanted to write a Thumb-2 assembler, took a long look at the instruction encoding and gave up.
Extremely nerdy sub-detail -- M-profile actually has all the handling for the Thumb-to-Arm switch architecturally, with the LSB of a branch target being significant and a T bit in the PSR to tell you what mode you're in, which you can set to 0. It's just that attempting to actually execute an insn with PSR.T==0 will trigger a UsageFault :-) (The CPU is even required to fetch the insn from memory first -- a MPU fault will take precedence over the T-bit-clear fault.)
> You essentially dump your cache when this happens, but you can do it.
Never heard of this and it makes no sense. The cache is pretty decoupled from the CPU pipeline. I saw a similar comment from someone discussion RISC-V mentioning that ARM/Thumb interworking is costly. I have no idea where these myths come from - really bizarre.
Used in some machines that were pretty cool at the time, like the tiny Jornada 680[1]. There was a Linux distro called Jlime that could run on these. https://en.wikipedia.org/wiki/Jlime
NetBSD has an active port (though "active" for NetBSD is not as "active" as other projects, but it still builds and runs): http://wiki.netbsd.org/ports/sh3/
Aside from the Dreamcast, there's a few Japanese NAS devices that run the SH3 port too.
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.
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.
With deeper pipelines, architectures with branch delay slots had to start emulating them for compatibility -- turning the performance/design advantage into a disadvantage.
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.
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.
Easily one of my favorite archs, at least as far as the idea of it goes. IMO the most pure classic 5 stage RISC. Divide is split into each cycle's ops, iterate for as long as your results need. It's pretty easy to get to a point where you can just read the hex of the opcodes as three address RISC with 16 bit instructions and 16 registers means the first nybble is the opcode, and the other three nybbles are the registers. And the whole thing feels like someone told some engineers that they have to make a RISC with half the gates of an equivalent MIPS and the mad lads actually did it, and did it well.
I had a completely irrational dislike for the division. You could use a loop, but then you were wasting >3/4ths of your cycles on shifting and branching. If you had the misfortune to have the compiler generate division code, it'd usually fill the branch delay slot with a NOP as well. The solution was simply to stick 8/16/32 division instructions in a row, but that felt inelegant. I spent a day writing some silly routine that averaged ~22 cycles over 32 bit integers just because it annoyed me so much.
Sadly not. I was pretty terrible about version control and saving things from that early in my career. The concept was pretty simple though: division was 1-bit so you could simply do fewer divisions if you had smaller numbers. The first version was something like a BSR -> jump into the divide table. That probably would have been the place to stop, but I was clearly terrible at profiling because I remember adding all sorts of special case logic on top to handle things like powers of two, which likely ended up being slower in practice because cycle times aren't everything.
> I was pretty terrible about version control and saving things from that early in my career.
You and everyone else, I feel. I tried to find some of my early projects from two decades back, and despite having backups floating around on various hard-drives, I could not find them to save my life. I wish I'd accepted the good word of CVS/SVN back then!
llvm has a cool tool to statically evaluate your code on a model scheduler [1]. Not sure how many backends are supported beyond x86, but it looks pretty handy.
Non-x86 architectures are vaguely supported, however the key thing here is that it needs a scheduler model i.e. architecture isn't enough. I think the basics of in-order target support is being worked on (possibly merged, haven't been keeping up to date)
Other tools to do this exist (or have existed, Intel IACA rest in peace), but I'm slightly sceptical how useful they are in practice.
They can't model anything transient in the processor (can't easily, at least) like branch prediction and the memory hierarchy. That and there's only so much detail one can fit inside a model.
> Divide is split into each cycle's ops, iterate for as long as your results need.
You know what would be better? If you had a decompression routine built into the CPU that would convert division and modulus commands into this loop at the micro-code level.
That way, a divide / modulus cycle (probably taking 20 instructions taking 50+ bytes) can be compressed into a singular instruction (1 instruction taking 4 bytes)... using less L1 cache.
I mean, it doesn't have any microcode, and does better than MIPS ironically at achieving the whole "Microprocessor without Interlocked Pipelined Stages" thing because of directly exposing the divide pipeline in single cycle units. Having to add pipeline interlocking from the EX stage just for that as well as the microcode itself would have been non trivial from a gate count perspective on a core that's already cutting gates left and right. And it's neat to be able to choose the divide precision you need down to the cycle.
I agree though in the general case, hence why I end with it being a little ascetic these days.
supposedly the j-core open core (sh compatible) isnt totally dead. the main patents seem to have run out, so implementation ought be ok. but definitely havent seen what the hopeful roadmap pitched happen: https://j-core.org/roadmap.html
They haven't come around to updating the page for a while (someone lost login info or something like that) but they have a new core and some projects that use the new SH4 equivalent core. https://www.coresemi.io/
They currently seem to be in a "release tarbal" model of open source but know they ought to be in an develop on master branch in public repo model.
I did some homebrew stuff for the Dreamcast back in the day with the KallistiOS stuff by Dan Potter.
I remember that you had to cross-compile from x86 to sh4 on windows and for that you had to first build the entire toolchain from scratch, my pentium 200MMX was not an ideal machine for that :D
It would have been interesting to see what would have happened to the SuperH architecture if Renesas decided to improve it instead of continually selling the same 200 MHz part with no die shrinks or improvements until people stopped buying them.
I wrote SH-3/4 simulators that were significantly faster than the actual parts. (The cheat was that the simulator ran that fast on an early 200MHz Pentium while the SH-3 was something like 35Mhz.)
I also wrote a synthesizable[1] SH-5 hardware model that was cycle and signal accurate at every module boundary and ran >100k cycles/second on said Pentium. (SH-5 was a 64 bit successor to the SH-4 that also had a 32 bit mode that ran SH-4 code. I don't know whether it ever shipped.)
[1] The cache, TLB, and floating-point weren't synthesizable. Making them synthesizable would have killed the cycles/second.
Have you written about your experiences developing this firmware and your involvement with the Telescope Array? I would be very interested to hear some of the stories (and lessons learned)!
I have a good friend however who is a great writer, and who has written a lot about her experiences, and who is working there again: https://www.jamiezvirzdin.com/
She didn't work much on the software/hardware side of things, however.
Maybe one day I'll sit down and put some of it to paper, I definitely have a lot of stories to tell.
In a previous space project we used SH2A because it was used successfully by colleagues previously, and had undergone the requisite radiation screening already.
It was obsoleted but we could get enough stock for the project. What we didn’t realize at the start was that the previous project had lower standards for development and testing and didn’t have the special debugger or great code. The debugger had to be special ordered for a ton of money and no vendors wanted to work on it.
Had a chance to revision up and changed to a pretty obscure atmega micro that was a perfect replacement. Did radiation screening again, development and testing..
That part was obsoleted too and I can’t use it for my next project. Will probably buy a space grade cpu for $20k this time. Radiation screening alone for a few components is $50k.
Which kind of debug probe did you use for it? I've been told that it's not regular OSS/OpenOCD/JTAG toolchain but something Hitachi-specific called H-UDI (proprietary JTAG extension)?
It was extremely expensive, and commercial, I'm honestly surprised I could even find a website for it.
It was extremely cool to basically scroll through memory, our hardware had an on-board FPGA that gathered waveforms from a photomultiplier tube attached to a scintillator, and when I was writing the driver for it, I could watch the memory in real-time with the debugger changing.
Setting initial values of memory to something like 0xDEADBEEF, and using this thing, was an incredibly powerful debugging strategy, especially when dealing with hardware.
I was not the one who put Linux on it (it is not my name on the paper, but I was there around that time), but I had fun making a NetMeeting like demonstration application on it. Well, there was no sound but I could get 5fps video! :D
Had the pleasure to announce the SH architecture and the SH-1 at the Microprocessor Forum in 1993. Maybe the first high performance embedded RISC device. Sega was the launch customer, but what we really wanted at he time was the hard disk market. Simple pitch: 10MIPS, 10M devices, $10 http://www.verycomputer.com/31_7a04bb69b4bdf1ee_1.htm
Was not a fan of the name SH, thought it was boring. Tried to get Hitachi to call it "Sonic" instead. As in (S)onic the (H)edgehog
SuperH competed with 68k and mips, perhaps? What do you think made the others more successful than SuperH? I suppose I dont know for sure that they were but I'll guess at least 68k lasted longer.
It didn’t compete with 68k which is much older traditional CISC processor which was never scaled up. The 68k died out with Apple switching to PPC except for embedded use where it lived on primarily with the Motorola Dragonball line. Freescale then licensed ARM cores for use in the MX series of MCUs that were briefly branded Dragonball as well. Competitors were PowerPC, MIPS and ARM and even x86 which was always a bit player even in embedded (and consoles sort of with the Xbox)
Very cool; takes me back down the memory lane.
We spun our own SH4-based SBC for the first prototype of this robot back in 2001: https://www.netl.doe.gov/node/3037
It was a fun architecture: 16-bit instruction set; 32-bit bus, and 64-bit vector instruction set. I actually got Linux running on it, but ended up running the code without any OS. We switched to an off-the-shelf ARM-based SBC for the next version of the robot.
The NetBSD SuperH ports (evbsh3, dreamcast, hpcsh, landisk) aren't horribly active, but they don't need to be - they run, and they run well. I have a NetBSD/landisk pkgsrc build machine which has been compiling continuously without any issues for more than a year.
We have quite a collection of SuperH binary packages:
70 comments
[ 5.4 ms ] story [ 142 ms ] threadOf several Busybox binaries for ARM, the v7m version is the smallest, and is (AFAIK) Thumb-only.
https://busybox.net/downloads/binaries/1.31.0-defconfig-mult...Never heard of this and it makes no sense. The cache is pretty decoupled from the CPU pipeline. I saw a similar comment from someone discussion RISC-V mentioning that ARM/Thumb interworking is costly. I have no idea where these myths come from - really bizarre.
[1] https://ed154c547559d2878d6a-e584b6b63c3a42919fe0cc5066a1430...
Aside from the Dreamcast, there's a few Japanese NAS devices that run the SH3 port too.
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
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.
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.
A little ascetic for these days though, IMO.
You and everyone else, I feel. I tried to find some of my early projects from two decades back, and despite having backups floating around on various hard-drives, I could not find them to save my life. I wish I'd accepted the good word of CVS/SVN back then!
(Found this a while back, mild impostor syndrome moment much)
[1] https://llvm.org/docs/CommandGuide/llvm-mca.html
https://reviews.llvm.org/D94928
Other tools to do this exist (or have existed, Intel IACA rest in peace), but I'm slightly sceptical how useful they are in practice.
They can't model anything transient in the processor (can't easily, at least) like branch prediction and the memory hierarchy. That and there's only so much detail one can fit inside a model.
You know what would be better? If you had a decompression routine built into the CPU that would convert division and modulus commands into this loop at the micro-code level.
That way, a divide / modulus cycle (probably taking 20 instructions taking 50+ bytes) can be compressed into a singular instruction (1 instruction taking 4 bytes)... using less L1 cache.
I agree though in the general case, hence why I end with it being a little ascetic these days.
They currently seem to be in a "release tarbal" model of open source but know they ought to be in an develop on master branch in public repo model.
J2 open processor: an open source processor using the SuperH ISA - https://news.ycombinator.com/item?id=26866065 - April 2021 (45 comments)
The SuperH-3, part 15: Code walkthrough - https://news.ycombinator.com/item?id=20779622 - Aug 2019 (1 comment)
The SuperH-3, part 1: Introduction - https://news.ycombinator.com/item?id=20622921 - Aug 2019 (2 comments)
Building a SuperH-compatible CPU from scratch [video] - https://news.ycombinator.com/item?id=11886079 - June 2016 (24 comments)
Resurrecting the SuperH architecture - https://news.ycombinator.com/item?id=9812010 - July 2015 (15 comments)
https://m.youtube.com/watch?v=dVD1Yws__v0
(open source GPS!)
J2 open processor: an open source processor using the SuperH ISA - https://news.ycombinator.com/item?id=26866065 - April 2021 (45 comments)
Why the J-core open processor is cool - https://news.ycombinator.com/item?id=24163584 - Aug 2020 (1 comment)
J-Core Open Processor - https://news.ycombinator.com/item?id=20658584 - Aug 2019 (31 comments)
J-core Open Processor - https://news.ycombinator.com/item?id=12105913 - July 2016 (27 comments)
Building a CPU from Scratch: Jcore Design Walkthrough [video] - https://news.ycombinator.com/item?id=12101908 - July 2016 (8 comments)
1) The compiler support for SuperH was beyond abysmal.
2) I loved that machine anyway.
I remember that you had to cross-compile from x86 to sh4 on windows and for that you had to first build the entire toolchain from scratch, my pentium 200MMX was not an ideal machine for that :D
I wrote SH-3/4 simulators that were significantly faster than the actual parts. (The cheat was that the simulator ran that fast on an early 200MHz Pentium while the SH-3 was something like 35Mhz.)
I also wrote a synthesizable[1] SH-5 hardware model that was cycle and signal accurate at every module boundary and ran >100k cycles/second on said Pentium. (SH-5 was a 64 bit successor to the SH-4 that also had a 32 bit mode that ran SH-4 code. I don't know whether it ever shipped.)
[1] The cache, TLB, and floating-point weren't synthesizable. Making them synthesizable would have killed the cycles/second.
I cut my embedded development teeth writing device drivers and custom firmware targeting it.
The reason we used SH4 is because the Dreamcast had failed, so there was a huge surplus of them available on the market at the time.
It was easily one of the most interesting and rewarding projects of my life to work on.
I have a good friend however who is a great writer, and who has written a lot about her experiences, and who is working there again: https://www.jamiezvirzdin.com/
She didn't work much on the software/hardware side of things, however.
Maybe one day I'll sit down and put some of it to paper, I definitely have a lot of stories to tell.
It was obsoleted but we could get enough stock for the project. What we didn’t realize at the start was that the previous project had lower standards for development and testing and didn’t have the special debugger or great code. The debugger had to be special ordered for a ton of money and no vendors wanted to work on it.
Had a chance to revision up and changed to a pretty obscure atmega micro that was a perfect replacement. Did radiation screening again, development and testing..
That part was obsoleted too and I can’t use it for my next project. Will probably buy a space grade cpu for $20k this time. Radiation screening alone for a few components is $50k.
I've never sent any hardware into space, but some former colleagues of mine were working on OWL around the time I left: https://asd.gsfc.nasa.gov/archive/owl/science.html
It was extremely expensive, and commercial, I'm honestly surprised I could even find a website for it.
It was extremely cool to basically scroll through memory, our hardware had an on-board FPGA that gathered waveforms from a photomultiplier tube attached to a scintillator, and when I was writing the driver for it, I could watch the memory in real-time with the debugger changing.
Setting initial values of memory to something like 0xDEADBEEF, and using this thing, was an incredibly powerful debugging strategy, especially when dealing with hardware.
> https://buildd.debian.org/status/architecture.php?a=sh4&suit...
Installer images are being built, too. But currently don’t boot due to an resolved bug in QEMU or the kernel:
> https://cdimage.debian.org/cdimage/ports/debian-installer/20...
If you’re interested in Linux on sh4, join the #debian-ports IRC channel on OFTC.
I’m the primary maintainer of the Debian sh4 port (and m68k, sparc64, x32, ia64, powerpc and ppc64).
I was not the one who put Linux on it (it is not my name on the paper, but I was there around that time), but I had fun making a NetMeeting like demonstration application on it. Well, there was no sound but I could get 5fps video! :D
Was not a fan of the name SH, thought it was boring. Tried to get Hitachi to call it "Sonic" instead. As in (S)onic the (H)edgehog
SuperH competed with 68k and mips, perhaps? What do you think made the others more successful than SuperH? I suppose I dont know for sure that they were but I'll guess at least 68k lasted longer.
It was a fun architecture: 16-bit instruction set; 32-bit bus, and 64-bit vector instruction set. I actually got Linux running on it, but ended up running the code without any OS. We switched to an off-the-shelf ARM-based SBC for the next version of the robot.
Debugging SH4 processors is tricky because they have a non-standard extension to JTAG standard: H-UDI.
Does anybody in this thread have details about the H-UDI proprietary SH4 JTAG extensions?
Context here:
https://github.com/GlasgowEmbedded/glasgow/discussions/290
We have quite a collection of SuperH binary packages:
http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/sh3el/9.0_2...