10 ms·

SuperH

ndiddy 5y ago
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.
- freemint 5y ago
  It is out of patent. Nobody prevents you from just doing that. But yeah it would be interesting to watch
chasil 5y ago
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-multiarch-musl/ https://busybox.net/downloads/binaries/1.31.0-defconfig-mult...
- tylerflick 5y ago
  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.
  - mananaysiempre 5y ago
    ... Except on ARM micros, where Thumb probably matters most nowadays, because Cortex-M only runs in Thumb mode.
    - duskwuff 5y ago
      And not on ARM64, which has no Thumb equivalent.
      - mananaysiempre 5y ago
        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.
      - Symmetry 5y ago
        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.
    - pm215 5y ago
      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.)
  - pm215 5y ago
    Why would a thumb/arm switch invalidate the caches? It's just an interworking branch, it isn't even a context switch.
  - danachow 5y ago
    > 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.
tyingq 5y ago
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 https://en.wikipedia.org/wiki/Jlime [1] https://ed154c547559d2878d6a-e584b6b63c3a42919fe0cc5066a14308.ssl.cf1.rackcdn.com/101889488_hp-hewlett-packard-jornada-680-handheld-pc-extras-ebay.jpg https://ed154c547559d2878d6a-e584b6b63c3a42919fe0cc5066a1430...
- tossaway9000 5y ago
  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/ http://wiki.netbsd.org/ports/sh3/ Aside from the Dreamcast, there's a few Japanese NAS devices that run the SH3 port too.
  - tyingq 5y ago
    Ah, okay...the Jornada is on their list too. http://wiki.netbsd.org/ports/hpcsh/hpcsh_support_status/ http://wiki.netbsd.org/ports/hpcsh/hpcsh_support_status/
spatulon 5y ago
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.
monocasa 5y ago
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.
- AlotOfReading 5y ago
  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.
  - freemint 5y ago
    Do you still have access to this?
    - AlotOfReading 5y ago
      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.
rektide 5y ago
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 https://j-core.org/roadmap.html
- tossaway9000 5y ago
  no update since August 31, 2016 seems pretty dead, though I guess there is someone around to renew the domain name, etc.
  - TapamN 5y ago
    There's some activity on the mailing list.
  - freemint 5y ago
    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/ 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.
- MaxBarraclough 5y ago
  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.
dang 5y ago
A few past related threads: J2 open processor: an open source processor using the SuperH ISA - https://news.ycombinator.com/item?id=26866065 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 https://news.ycombinator.com/item?id=20779622 - Aug 2019 (1 comment) The SuperH-3, part 1: Introduction - https://news.ycombinator.com/item?id=20622921 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 https://news.ycombinator.com/item?id=11886079 - June 2016 (24 comments) Resurrecting the SuperH architecture - https://news.ycombinator.com/item?id=9812010 https://news.ycombinator.com/item?id=9812010 - July 2015 (15 comments)
- eggsome 5y ago
  Here is my current favorite: https://m.youtube.com/watch?v=dVD1Yws__v0 https://m.youtube.com/watch?v=dVD1Yws__v0 (open source GPS!)
  - dang 5y ago
    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 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 https://news.ycombinator.com/item?id=24163584 - Aug 2020 (1 comment) J-Core Open Processor - https://news.ycombinator.com/item?id=20658584 https://news.ycombinator.com/item?id=20658584 - Aug 2019 (31 comments) J-core Open Processor - https://news.ycombinator.com/item?id=12105913 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 https://news.ycombinator.com/item?id=12101908 - July 2016 (8 comments)
PandaPanda150 5y ago
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.
- gkhartman 5y ago
  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.
- vernie 5y ago
  Which games?
- Bad_CRC 5y ago
  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
- braincode 5y ago
  Which kind of JTAG/debug probe did you use for the Dreamcast? Does it even have such a port exposed and enabled?
xony 5y ago
i loved J-core , it showed the importance of ISA .. RISC-V & J-core can change this world ..
anamax 5y ago
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.
thedracle 5y ago
We used SH4 chips for the cosmic-ray surface detector array for the Telescope Array project: http://telescopearray.org/ 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.
- braincode 5y ago
  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)?
  - thedracle 5y ago
    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 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.
- jwuphysics 5y ago
  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)!
  - thedracle 5y ago
    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/ 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.
cbmuser 5y ago
FWIW, we’re still building an unofficial port of Debian for sh4: > https://buildd.debian.org/status/architecture.php?a=sh4&suite=sid 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/2021-10-20/sh4/ 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).
- matoro 5y ago
  Is there any sh4 or m68k hardware available that is capable of self-hosting?
- wyldfire 5y ago
  Cool! Is there a good starting point for instructions on porting to a new architecture?
aconst 5y ago
Worked on this while an intern in Ricoh in Japan : https://www.kernel.org/doc/ols/2004/ols2004v2-pages-239-250.pdf 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
- braincode 5y ago
  Fascinating, which kind of JTAG fixture did you use for this device and which debugger did you use? kdb?
paul_f 5y ago
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 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
- wyldfire 5y ago
  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.
  - danachow 5y ago
    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)
- eska 5y ago
  I hope this will make your day better then: https://en.wikipedia.org/wiki/Sonic_hedgehog https://en.wikipedia.org/wiki/Sonic_hedgehog
georgecmu 5y ago
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 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.
malkia 5y ago
Wow... dreamcast... CodeWarrior - OMG... RUN FOR YOUR LIVES....
braincode 5y ago
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 https://github.com/GlasgowEmbedded/glasgow/discussions/290
johnklos 5y ago
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_2021Q3/All/ http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/sh3el/9.0_2...

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.

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

chasil 5y ago

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-multiarch-musl/ https://busybox.net/downloads/binaries/1.31.0-defconfig-mult...

tylerflick 5y ago
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.
- mananaysiempre 5y ago
  ... Except on ARM micros, where Thumb probably matters most nowadays, because Cortex-M only runs in Thumb mode.
  - duskwuff 5y ago
    And not on ARM64, which has no Thumb equivalent.
    - mananaysiempre 5y ago
      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.
    - Symmetry 5y ago
      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.
  - pm215 5y ago
    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.)
- pm215 5y ago
  Why would a thumb/arm switch invalidate the caches? It's just an interworking branch, it isn't even a context switch.
- danachow 5y ago
  > 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.

tyingq 5y ago

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 https://en.wikipedia.org/wiki/Jlime [1] https://ed154c547559d2878d6a-e584b6b63c3a42919fe0cc5066a14308.ssl.cf1.rackcdn.com/101889488_hp-hewlett-packard-jornada-680-handheld-pc-extras-ebay.jpg https://ed154c547559d2878d6a-e584b6b63c3a42919fe0cc5066a1430...

tossaway9000 5y ago
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/ http://wiki.netbsd.org/ports/sh3/ Aside from the Dreamcast, there's a few Japanese NAS devices that run the SH3 port too.
- tyingq 5y ago
  Ah, okay...the Jornada is on their list too. http://wiki.netbsd.org/ports/hpcsh/hpcsh_support_status/ http://wiki.netbsd.org/ports/hpcsh/hpcsh_support_status/

spatulon 5y ago

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.

monocasa 5y ago

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.

AlotOfReading 5y ago
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.
- freemint 5y ago
  Do you still have access to this?
  - AlotOfReading 5y ago
    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.

rektide 5y ago

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 https://j-core.org/roadmap.html

tossaway9000 5y ago
no update since August 31, 2016 seems pretty dead, though I guess there is someone around to renew the domain name, etc.
- TapamN 5y ago
  There's some activity on the mailing list.
- freemint 5y ago
  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/ 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.
MaxBarraclough 5y ago
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.

dang 5y ago

A few past related threads: J2 open processor: an open source processor using the SuperH ISA - https://news.ycombinator.com/item?id=26866065 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 https://news.ycombinator.com/item?id=20779622 - Aug 2019 (1 comment) The SuperH-3, part 1: Introduction - https://news.ycombinator.com/item?id=20622921 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 https://news.ycombinator.com/item?id=11886079 - June 2016 (24 comments) Resurrecting the SuperH architecture - https://news.ycombinator.com/item?id=9812010 https://news.ycombinator.com/item?id=9812010 - July 2015 (15 comments)

eggsome 5y ago
Here is my current favorite: https://m.youtube.com/watch?v=dVD1Yws__v0 https://m.youtube.com/watch?v=dVD1Yws__v0 (open source GPS!)
- dang 5y ago
  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 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 https://news.ycombinator.com/item?id=24163584 - Aug 2020 (1 comment) J-Core Open Processor - https://news.ycombinator.com/item?id=20658584 https://news.ycombinator.com/item?id=20658584 - Aug 2019 (31 comments) J-core Open Processor - https://news.ycombinator.com/item?id=12105913 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 https://news.ycombinator.com/item?id=12101908 - July 2016 (8 comments)

PandaPanda150 5y ago

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.

gkhartman 5y ago
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.
vernie 5y ago
Which games?
Bad_CRC 5y ago
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
braincode 5y ago
Which kind of JTAG/debug probe did you use for the Dreamcast? Does it even have such a port exposed and enabled?

xony 5y ago

i loved J-core , it showed the importance of ISA .. RISC-V & J-core can change this world ..

anamax 5y ago

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.

thedracle 5y ago

We used SH4 chips for the cosmic-ray surface detector array for the Telescope Array project: http://telescopearray.org/ 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.

braincode 5y ago
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)?
- thedracle 5y ago
  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 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.
jwuphysics 5y ago
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)!
- thedracle 5y ago
  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/ 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.

cbmuser 5y ago

FWIW, we’re still building an unofficial port of Debian for sh4: > https://buildd.debian.org/status/architecture.php?a=sh4&suite=sid 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/2021-10-20/sh4/ 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).

matoro 5y ago
Is there any sh4 or m68k hardware available that is capable of self-hosting?
wyldfire 5y ago
Cool! Is there a good starting point for instructions on porting to a new architecture?

aconst 5y ago

Worked on this while an intern in Ricoh in Japan : https://www.kernel.org/doc/ols/2004/ols2004v2-pages-239-250.pdf 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

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

paul_f 5y ago

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

wyldfire 5y ago
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.
- danachow 5y ago
  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)
eska 5y ago
I hope this will make your day better then: https://en.wikipedia.org/wiki/Sonic_hedgehog https://en.wikipedia.org/wiki/Sonic_hedgehog

georgecmu 5y ago

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

malkia 5y ago

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

braincode 5y ago

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 https://github.com/GlasgowEmbedded/glasgow/discussions/290

johnklos 5y ago

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_2021Q3/All/ http://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/sh3el/9.0_2...