We used SH4 chips for the cosmic-ray surface detector array for the Telescope Array project: <a href="http://telescopearray.org/" rel="nofollow">http://telescopearray.org/</a><p>I cut my embedded development teeth writing device drivers and custom firmware targeting it.<p>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.<p>It was easily one of the most interesting and rewarding projects of my life to work on.
A few past related threads:<p><i>J2 open processor: an open source processor using the SuperH ISA</i> - <a href="https://news.ycombinator.com/item?id=26866065" rel="nofollow">https://news.ycombinator.com/item?id=26866065</a> - April 2021 (45 comments)<p><i>The SuperH-3, part 15: Code walkthrough</i> - <a href="https://news.ycombinator.com/item?id=20779622" rel="nofollow">https://news.ycombinator.com/item?id=20779622</a> - Aug 2019 (1 comment)<p><i>The SuperH-3, part 1: Introduction</i> - <a href="https://news.ycombinator.com/item?id=20622921" rel="nofollow">https://news.ycombinator.com/item?id=20622921</a> - Aug 2019 (2 comments)<p><i>Building a SuperH-compatible CPU from scratch [video]</i> - <a href="https://news.ycombinator.com/item?id=11886079" rel="nofollow">https://news.ycombinator.com/item?id=11886079</a> - June 2016 (24 comments)<p><i>Resurrecting the SuperH architecture</i> - <a href="https://news.ycombinator.com/item?id=9812010" rel="nofollow">https://news.ycombinator.com/item?id=9812010</a> - July 2015 (15 comments)
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.<p>A little ascetic for these days though, IMO.
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 <a href="http://www.verycomputer.com/31_7a04bb69b4bdf1ee_1.htm" rel="nofollow">http://www.verycomputer.com/31_7a04bb69b4bdf1ee_1.htm</a><p>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
I used to work in automotive software, where the SH-2A was a popular choice for engine controller units, particularly in Japan.<p>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.<p>The SH-4 was most notably used in the Sega Dreamcast.<p>[1]: <a href="https://en.wikipedia.org/wiki/Delay_slot" rel="nofollow">https://en.wikipedia.org/wiki/Delay_slot</a>
FWIW, we’re still building an unofficial port of Debian for sh4:<p>> <a href="https://buildd.debian.org/status/architecture.php?a=sh4&suite=sid" rel="nofollow">https://buildd.debian.org/status/architecture.php?a=sh4&suit...</a><p>Installer images are being built, too. But currently don’t boot due to an resolved bug in QEMU or the kernel:<p>> <a href="https://cdimage.debian.org/cdimage/ports/debian-installer/2021-10-20/sh4/" rel="nofollow">https://cdimage.debian.org/cdimage/ports/debian-installer/20...</a><p>If you’re interested in Linux on sh4, join the #debian-ports IRC channel on OFTC.<p>I’m the primary maintainer of the Debian sh4 port (and m68k, sparc64, x32, ia64, powerpc and ppc64).
ARM Thumb is similar in design, and the wiki says that ARM licensed SuperH patents to implement it.<p>Of several Busybox binaries for ARM, the v7m version is the smallest, and is (AFAIK) Thumb-only.<p><pre><code> busybox-armv5l 2019-06-10 14:02 1.1M
busybox-armv7l 2019-06-10 14:02 1.1M
busybox-armv7m 2019-06-10 14:02 867K
busybox-armv7r 2019-06-10 14:02 1.1M
busybox-armv8l 2019-06-10 14:02 1.1M
busybox-sh2eb 2019-06-10 14:02 1.3M
busybox-sh4 2019-06-10 14:02 1.0M
</code></pre>
<a href="https://busybox.net/downloads/binaries/1.31.0-defconfig-multiarch-musl/" rel="nofollow">https://busybox.net/downloads/binaries/1.31.0-defconfig-mult...</a>
I wrote a couple of games for the SEGA Dreamcast. There are two things that I remember from back then:<p>1) The compiler support for SuperH was beyond abysmal.<p>2) I loved that machine anyway.
That takes me back.<p>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.)<p>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.)<p>[1] The cache, TLB, and floating-point weren't synthesizable. Making them synthesizable would have killed the cycles/second.
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.
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. <a href="https://en.wikipedia.org/wiki/Jlime" rel="nofollow">https://en.wikipedia.org/wiki/Jlime</a><p>[1] <a href="https://ed154c547559d2878d6a-e584b6b63c3a42919fe0cc5066a14308.ssl.cf1.rackcdn.com/101889488_hp-hewlett-packard-jornada-680-handheld-pc-extras-ebay.jpg" rel="nofollow">https://ed154c547559d2878d6a-e584b6b63c3a42919fe0cc5066a1430...</a>
This post is so timely!<p>Debugging SH4 processors is tricky because they have a non-standard extension to JTAG standard: H-UDI.<p>Does anybody in this thread have details about the H-UDI proprietary SH4 JTAG extensions?<p>Context here:<p><a href="https://github.com/GlasgowEmbedded/glasgow/discussions/290" rel="nofollow">https://github.com/GlasgowEmbedded/glasgow/discussions/290</a>
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: <a href="https://www.netl.doe.gov/node/3037" rel="nofollow">https://www.netl.doe.gov/node/3037</a><p>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.
Worked on this while an intern in Ricoh in Japan : <a href="https://www.kernel.org/doc/ols/2004/ols2004v2-pages-239-250.pdf" rel="nofollow">https://www.kernel.org/doc/ols/2004/ols2004v2-pages-239-250....</a><p>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
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.<p>We have quite a collection of SuperH binary packages:<p><a href="http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/sh3el/9.0_2021Q3/All/" rel="nofollow">http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/sh3el/9.0_2...</a>
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: <a href="https://j-core.org/roadmap.html" rel="nofollow">https://j-core.org/roadmap.html</a>