I turn 27 years old today, which feels both very old and very young. 30 is often seen as a milestone, perhaps because you have spent nearly a decade operating as an “adult”, but likely are still considered in the earlier part of your career. I am a firm believer that doing most things of significance takes at least 3 years, which makes 27 a good time to decide to commit to “doing something before you are 30”. As such, I am committing to gaining a deep understanding of chip design through practice.
Motivation Link to heading
It is no secret that I have been interested in the hardware-software interface for the better part of my 20s. From my speaking and writing, to my recent career moves, I have slowly been moving closer to the physical layer of computing. However, though I have spent time personally studying chip design, I have not invested the requisite amount of time to obtain what I would consider a deep understanding.
Coincidentally, it’s an interesting time to be working on chip design, primarily for the following reasons:
- Constraints: The end of Dennard Scaling and the slowing of Moore’s Law has led to an increased focus on Application Specific Integrated Circuits (ASIC) and Domain-Specific Accelerators (DSA).
- Accessibility: The rise of a commercially viable open source instruction set (RISC-V) has resulted in more processor reference implementations being made available on the internet.
- Demand: The emphasis on machine learning and artificial intelligence and the “embarassingly parallel” nature of model training and inference has drastically increased the demand for processors designed to support the paradigm.
But these are not the core motivation for why I am making the commitment. At an even more fundamental layer, I am deeply bothered by our collective acceptance of lack of transparency in hardware design. The more I have explored the space, the more similar software and hardware have started to appear. In fact, at this point it feels as though the difference between implementing logic in software vs. in hardware is not so different from using one software programming model rather than another.
Despite these similarities, we hold hardware (and some firmware) to a very different standard than software. It is almost as if we believe that hardware is somehow more constrained than software, when, in reality, the opposite is true. One outlook is that understanding the entire system down to the silicon is simply too complicated. We have to accept abstractions, and hardware is the interface in which the divergence between the world on one side is perhaps the most significant from the world on the other. But I’m not buying it. I don’t think everyone should have to understand how their processor works, but I do think they should be able to if they want to. And ideally future folks shouldn’t also have to commit three years of their life to do so.
Plan Link to heading
Passion without a plan is not a recipe for success. At the same time, when committing to a somewhat open-ended endeavor, building flexibility and space into a plan allows for “penalty-free” adjustments. In this case, success looks like consistency. Over the past 2 years, I have intermittently worked on the Moss Computer Project, and have experimented with live streaming my efforts.
As stated in the
moss README.md, the
intention of the project is to design a computer that is both competitive in
performance and exceedingly understandable by users. The former goal is a check
on the latter — a computer that is exceedingly understandable, but not
representative of the modern processors and peripherals we use today, has no
hope of influencing our expectations of production quality hardware. In some
ways, designing a processor that is competitive in performance seems easier than
designing one that is understandable, primarily because the latter is so
subjective. However, I have no doubt that if I am loud enough on the internet,
there will be plenty of folks who are willing to weigh in on the matter.
And regularly being loud on the internet is essentially my plan. To start out, I am committing to one live stream / video per month and one blog post per week related to my work on the Moss Computer Project. An important caveat is that the length and content of these artifacts is undefined. While my typical modus operandi is writing long, in-depth posts, they do not cater well to maintaining a consistent practice, especially when my day job and other responsibilities demand a great deal of time and effort. I anticipate some posts being as short as a few sentences describing what I thought about that week.
Getting Involved Link to heading
While there will certainly be ways to more formally get involved in the Moss Computer Project in the future, the best way in the short-term is to simply to engage with the content and provide feedback. If you are interested in this space, I’d love to have you join a live stream or pre-recorded conversation.
You can find artifacts at the following locations:
- Code: https://github.com/mosscomp
- Live Streams: https://www.youtube.com/@hasheddan
- Blog Posts: https://danielmangum.com/categories/moss
Otherwise, I’ll see y’all back here on July 19, 2026.