HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
tommythorn
fpgammix
C2016–2022
tommythorn / fpgammix

fpgammix

Partial implementation of Knuth's MMIX processor (FPGA softcore)

2Distinct people
4Mentions
0Explicit recommenders
60GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Partial implementation of Knuth's MMIX processor (FPGA softcore)

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year4 dated mentions

Observed mentions: 2016-02-11 17:55:43 UTC to 2022-07-03 13:02:26 UTC.

0122016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments20162017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2022

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC202
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC000
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC000
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC000
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC000
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101

What Hacker News says

4 sources
[I'm well aware of who I am replying to here, I'm merely taking the bait and providing some hopefully fun links for people to dig into. :)] Because that's how Professor Wirth ¹) does it ²), because it allows for some interesting educational side-treks ³), and because the difference between a fictional and real microprocessor is smaller than some might think ⁴). ¹) https://people.inf.ethz.ch/wirth/index.html ²) https://people.inf.ethz.ch/wirth/CompilerConstruction/index.... ³) "So what instruction would you add to this CPU to make the work we've been doing easier? Great, implement that instruction in the provided emulator." ⁴) https://people.inf.ethz.ch/wirth/FPGA-relatedWork/index.html (edit: And, of course, there's FPGA implementations of Professor Knuth's MMIX (http://mmix.cs.hm.edu/), too: https://github.com/tommythorn/fpgammix)
In An engineer’s tips for writing documentation devs love
(EDIT: typos galore) Thank you. Boy, this was a long time ago and I haven't written anything. I suspect it will be obvious for anyone skilled in the act, but I had to go look at my code at bit to remember some of this. First a quick word from the POV of a compiler: the register windows are supposed to make function call easier and I suppose it works as designed for hand written code, but it actually adds a lot of complexity to indirect call/virtual functions and is a disaster for anything that switches stack (context switches, coroutines, etc). Another problem is the immediate fields which are just 8-bit unsigned, very often too small. And in practical terms, the GCC port really struggles to make good code for MMIX. Try it! From the implementation POV: even ignoring the resource requirement for the full MMIX (which besides 256 registe
Read the rest
rs includes a LOT of functionality), it's hard to pipeline as MMIX actually have fairly complicated semantics; just look at the state machine, the S_XXX symbols in https://github.com/tommythorn/fpgammix/blob/master/rtl/core.... While you can obviously deal with that (as witnessed by x86), it requires you to speculate a lot (for starters, speculate that you didn't get an interrupt). All speculation add complication as you need to recover from mis-speculation. This in term hurts cycle time by making stages more complicated and is a MAJOR source of verification work (AKA bugs). My implementation is nearly completely un-pipelined, very similar to a simple interpreter but in Verilog. Once I had enough functionality that I could look back and consider a more realistic implementation, I really lost the enthusiasm and instead focused on MIPS which is dramatically more efficient and easier to implement (pesky branch delay-slot not withstanding). Of course, later a friend leaked word of nascent RISC-V and the world was forever different. I actually asked Don directly why he hadn't gone with something like MIPS, but he answered vaguely that he wanted something for education. On the positive side, I found a bug and scored a $2.56 check (real dollars) and a couple of MMIX T-shirts :)
In 6th RISC-V Workshop Proceedings
If you consider an FPGA board real hardware, then yes, I've run MMIX programs, including graphics, on real hardware: https://github.com/tommythorn/fpgammix Caveats: this is some of the worst Verilog I've even written; I was explicitly racing ahead learning about MMIX as I went along. In the end I had a large subset (integer usermode) when I abandoned it. As much as I wanted to like it, it's really a pretty terrible architecture from most perspectives: it's impossible to scale down, hard to scale up, and nearly impossible to generate good code for. In contrast, RISC-V is IMO the nicest RISC ISA ever design.
In 6th RISC-V Workshop Proceedings

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.