Hacker News Reader

Comment by JulianMorrison | Hacker News Reader

A FPGA, huh? Interesting, why not just target ARM? I doubt that's going anywhere soon.

I imagine Prof. Wirth must have thought that 32032 wasn't going anywhere soon 20 years ago.

As I see it, the ARM instruction sets (note the use of plural) are a moving target (look at Cortex chips with Thumb2 only). They are far from RISC if you count them, and the instruction encoding is horrendulous.

It's like saying "why not target Windows? I doubt that's going anywhere soon"

With FPGAs, your only risk is that the manufacturer discontinues the chip you targeted, and you can then target another brand with the same (or nearly the same) HDL code.

100% spot on assessment! Wirth thought ahead well enough last time in making it modular and simple enough to easily port. They thought even better by putting it on a FPGA. And also with CPU and components simple enough to implement on ASIC with old node (350nm or 180nm). That's inexpensive enough to be crowd-funded.

Need the I/O stuff, etc to be implemented for the node, too, though...

Thanks. And I didn't even mention security in ARM chips (or lack thereof)

20 years ago was 1995. NS32k was long dead then; National retired it in 1990 when it was only six years old. Even when it came out, it was kind of an underdog compared the the already-five-year-old 68k, which was already powering the SUN workstations and went on to power any number of Sun competitors plus the Lisa, the Macintosh, and the PalmPilot.

ARM has been around at this point for 30 years, and yes, there are incompatibilities from one to the next. But it'll probably be around in some form for another 30 years.

And, yes, your Windows binaries will probably still be runnable ten years from now, and your Linux binaries probably won't be.

I imagine Wirth chose 32032 for its purported elegance, not its longevity or commercial practicality. As I recall they had all sorts of initial problems and then lost the war for that market segment against the 68k.

I have heard many people talk about the NS32k in positive overall terms, I've researched it a few times, it looks like a nice CISC architecture, but not different/better enough than the 68k at the time.

I do recall the team under Jack Tramiel at Atari looked into the NS32k for their new 16/32-bit system, and even built a prototype, and then tossed it in favour of 68k because of purported bugs in the NS32k.

The 32032 instruction set was wonderful to generate code for. There were a few early bugs (if a floating point instruction crossed a page boundary, and a page fault was triggered, hilarity would ensue), but those were ironed out well before the chip was abandoned.

There also exist Oberon systems targeting ARM I think.

I assume the motivation for FPGA is the original Oberon idea: "its primary goal was to design and implement an entire system from scratch, and to structure it in such a way that it can be described, explained, and understood as a whole." (The original 1985 Oberon system was also running on custom FPGA hardware.)

Real "Full-stack" development. :)

I'll add that ARM is a sue-happy organization whose processor licenses cost $1-15 million. MIPS gets so much traction in embedded space by charging a mere $700-900 thousand dollars. If we consider cost to implement, then the tiniest and legally-clear ISA possible makes the most sense.

However, my usual recommendation is SPARC given its ecosystem, openness, and mere $99 registration free. RISC-V, esp Rocket processor, will hopefully take its place. A custom, tiny RISC chip on a FPGA? Ok, ok, Wirth... that is more practical... (sighs) Lol...

he means, why use a FPGA instead of an ARM cpu. Not ARM on the FPGA.

I know what he means. As the other commenter pointed out, the question is whether ARM will be as popular 10+ years down the road. The chip Oberon was on was very popular back then. Not any more. So, they had to re-write significant portions of it to support new hardware.

Wirth decided it would be better to make a simple, custom processor that follows the spirit of the system. That by itself would be a fun project. He could put it on any current and future FPGA, something very unlikely to disappear. He then ported Oberon to it. Now, it's future-proof.

yes, but you are allowed to use ARM's ISA via an actual arm chip (not in an FPGA, obviously.)

Maybe I worded it unclearly. The original version of Oberon ran on a popular, embedded chip. Those don't exist any more despite that people at the time thought they'd be around forever. The risk exists with ARM but less.

Oberon-related tech is also training for ETH students. They get plenty of experience trying to extend the OS, port the compilers, etc. They have little in hardware by comparison, though. FPGA's have gotten cheap and their nature means they'll stay around in some form forever. Verilog also goes back decades. So, there's the added benefit of teaching students to build a processor which could also run the system.

So, combining future-proofing, simplicity, OS education, and HW education requirements all into one meant a custom, Wirth-style processor on FPGA was best option. It also creates opportunities for things like TCP/IP, graphics, or security engines he probably didn't think about at the time. His students or FOSS volunteers might pick that up given how simple the HW is.

So, ARM is a bad idea. Those SOC's are too complex. Extending or re-implementing it needs a ridiculously-expensive license. They also sue people over even using the ISA, which makes me boycott them where possible. The FPGA doesn't have these problems plus allowed he and his students to attempt an ideal replacement that could last decades. So, that was his choice and one of the better options.

Note: I'd have used it as an excuse to get some grant money to do a full, low-cost, RISC-V implementation to put A2 Bluebottle on. More practical. That's just me, though. ;)

It would mean compromising the theme there of consistency-all-the-way-down.

What I would like to see instead would be RISC-V instead of their own ISA. At least there some learnings could be shared with other academics and tinkerers.

ISA compatibility is overrated.

Tell that to the companies trying to push MIPS SOC's for Android smartphones. If it isn't ARM, they tell them to get lost. Likewise, for x86 + Windows. As ARM and Intel themselves say, being able to leverage the ecosystem of existing code, tools, talent, and so on is a huge differentiator. ARM on mobile (esp iOS & Android) has a massive ecosystem and many tool vendors whereas RISC-V or Wirth's CPU's don't have jack. So, manufacturers explicitly require ARM for high-end smartphones and SOC makers default on it despite ridiculous licensing cost.

Note: Areas like embedded in general with smaller, custom jobs don't worry about ISA's as much. Plenty of ARM, MIPS, PPC, x86, SPARC, Super-H, 16bits, 8bits... you name it. Much more fun space to be a programmer if you get to pick the cpu/board. :)

I'm in the GPU business. Here, ISA compatibility does not even exist and nobody cares. As long as you own an entire toolchain - a GLES/OpenCL driver, or, as in this case, an Oberon OS and a compiler - nobody gives a tiniest bit of crap about the underlying ISA.

So, I do not see any reason for the Oberon machine to rely on any "standard" ISA. It can even be compiled into some kind of a NISC, and nobody would notice any difference.

Oh I agree about Oberon and GPU's. My argument is for mainstream market for software in desktops and mobile. The ISA usually does matter.

Now, if we're talking GPU's, the effective ISA would be DirectX, OpenGL, OpenCL, etc. They're the standards that software and tooling target. So, does you product get by with not supporting any of those? Or do you have to comply with the your niche's standard interfaces and ecosystems, too?

In this case, Oberon itself is an ISA. You do not care about anything below its level.

Wirth explains in one of his articles that designing the compiler and the CPU together simplifies both.

Reply on news.ycombinator.com