SuperH | Hacker News Reader

SuperH

en.wikipedia.org

We used SH4 chips for the cosmic-ray surface detector array for the Telescope Array project: http://telescopearray.org/

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.

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.

I worked on some data acquisition software that was in a beam-line (SLAC), but we just made sure to surround everything with lead bricks.

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

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 haven't, to be honest I'm not much of a writer.

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.

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)?

So, it was a long time ago, and I did use a JTAG emulator/debugger called the "Partner JET:" https://www.kmckk.co.jp/eng/gigatrace_index.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.

I was thinking "cool, like the dreamca....oh ... ok..."

A few past related threads:

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)

Here is my current favorite:

https://m.youtube.com/watch?v=dVD1Yws__v0

(open source GPS!)

Ah - that led me to these. Thanks!

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)

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.

A little ascetic for these days though, IMO.

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.

Do you still have access to this?

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!

This is not an answer to your question as asked, but the direction it goes may prove interesting: https://lab.whitequark.org/notes/2020-04-06/synthesizing-opt...

(Found this a while back, mild impostor syndrome moment much)

whitequark is pretty genius. I think i saw that on her twitter previously but thanks for the trip down memory lane.

Branch delay slots make. assembly weird

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.

[1] https://llvm.org/docs/CommandGuide/llvm-mca.html

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)

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.

Go away NOP!

> 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.

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

I hope this will make your day better then: https://en.wikipedia.org/wiki/Sonic_hedgehog

That'd have been a neat co-branding opportunity!

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)

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

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.

Do you have a link to the proposal?

FWIW, we’re still building an unofficial port of Debian for sh4:

> 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).

Is there any sh4 or m68k hardware available that is capable of self-hosting?

Cool! Is there a good starting point for instructions on porting to a new architecture?

ARM Thumb is similar in design, and the wiki says that ARM licensed SuperH patents to implement it.

Of several Busybox binaries for ARM, the v7m version is the smallest, and is (AFAIK) Thumb-only.

    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

https://busybox.net/downloads/binaries/1.31.0-defconfig-mult...

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.

> 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.

... Except on ARM micros, where Thumb probably matters most nowadays, because Cortex-M only runs in Thumb mode.

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.)

And not on ARM64, which has no Thumb equivalent.

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.

Which makes sense. If you want 64 bit pointers you probably don't have so little memory that you're looking to compress your binaries.

Why would a thumb/arm switch invalidate the caches? It's just an interworking branch, it isn't even a context switch.

I wrote a couple of games for the SEGA Dreamcast. There are two things that I remember from back then:

1) The compiler support for SuperH was beyond abysmal.

2) I loved that machine anyway.

Any interesting stories from back then? I'd love to hear about any hacks that were unique to Dreamcast if you're willing to share.

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

Which kind of JTAG/debug probe did you use for the Dreamcast? Does it even have such a port exposed and enabled?

Which games?

That takes me back.

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.

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.

It is out of patent. Nobody prevents you from just doing that. But yeah it would be interesting to watch

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

[1] https://ed154c547559d2878d6a-e584b6b63c3a42919fe0cc5066a1430...

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.

Ah, okay...the Jornada is on their list too. http://wiki.netbsd.org/ports/hpcsh/hpcsh_support_status/

This post is so timely!

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

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.

Worked on this while an intern in Ricoh in Japan : https://www.kernel.org/doc/ols/2004/ols2004v2-pages-239-250....

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

Fascinating, which kind of JTAG fixture did you use for this device and which debugger did you use? kdb?

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:

http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/sh3el/9.0_2...

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

A pity the J2 never got any traction. I wonder why. RISC-V is doing great; it's not as if there's no interest in unencumbered ISAs.

no update since August 31, 2016 seems pretty dead, though I guess there is someone around to renew the domain name, etc.

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.

There's some activity on the mailing list.

Wow... dreamcast... CodeWarrior - OMG... RUN FOR YOUR LIVES....

Reply on news.ycombinator.com