Mark 1 Forth Computer (2006)
aholme.co.uk
aholme.co.uk
That said, some nits on the author's description, what he calls "micro code" are simply instructions. When you look at computer architecture texts you will see that architectures that implement instructions with logic are "non-microcoded" and architectures that implement instructions of one width as a sequence of instructions of a different width, are "microcoded". The trade-off is that that former executes operation codes faster, the latter can be more efficiently implemented. A great real world example to study here are the PDP-8 (straight opcodes) and the PDP-11 (microcoded).
The most amazing thing to me is that today you can buy something like the ULX3S[2] and with a fully open source tool chain for the FPGA build a processor (RISCV) that boots Linux multi-user.
[1] Using a pre-made ALU is fine, starting from a previous CPU, less good :-).
When commercial computers were built from discrete logic in this manner, there was distinction between "horizontal" and "vertical" microcode. With horizontal being what most people would today call microcode, ie. implementing most of the control logic as one somewhat wide memory array with datapath being mostly directly controlled by bits coming form such memory. The vertical approach essentially involved designing simplistic RISC-like CPU with fixed width instructions which then ran interpreter for the actual instruction stream of the machine (ie. what the author's CPU does). And obviously there are various middle-ground approaches. The reason for this is that control-stores for purely horizontal microcode are not that dense and involve memory with weird and large word lengths (which is somewhat inconvenient for implementation from commercially available (P)ROM chips)
Is there any like definitive book or website to learn any of this stuff?
The NES or Gameboy are great little machines that are easy to understand and have tons of guides, tutorials, and tools available.
With very little investment, you can even get run homebrew software on actual hardware.
As far as learning assembly, you may want to try Zachtronics games TIS-100, Shenzhen.IO, and Exapunks as it does offer a bit of the instinct for assembly coding. To learn 6502, I could suggest finding yourself a good C-128 emulator. The C-128 how I learned both basic and assembly (using their MONITOR command) and the 6502 is pretty easy to understand even if underpowered.
If it’s the former, I generally agree. It does not take long - I worked through nandgame.com over a slow afternoon and it helped me refresh things that I remembered fuzzily.
If it’s the latter, I think it is too high an ask nowadays where so many people work at a high abstraction level.
This logic would've worked in 1985 and maybe, just maybe until 1993. Modern CPUs cannot be programmed at the level that TTL provides. The µArch itself has long since become an abstraction in and of itself.
Depending on the instruction set, there's often no way to predict beforehand how certain data- and code paths will behave. That's why modern compilers use optimisation techniques such as profile guided optimisation.
If you think that certain µArchs are easier to understand in that regard than others (e.g. x86 vs ARM), think again. There's inaccessible embedded hardware [0], and SoCs hidden behind proprietary RTOSes [1] that prevent direct access.
Detailed knowledge about building the hardware is therefore only of very limited use in real-world applications; unless you plan to become a firmware-, driver-, or compiler developer.
Even in the embedded world, data sheets can be deceiving and ultimately knowing your (compiler-) toolchain and knowing how to test the behaviour in practise is far more valuable.
General knowledge should be required, yes, but going so far as to build an actual computer "from scratch" isn't as helpful as it might seem.
[0] https://news.ycombinator.com/item?id=25801500 [1] https://en.wikipedia.org/wiki/VideoCore
There's a close and obvious relationship between C statements and the PDP-11 instruction set. And at least one PDP-11 series processor was implemented with gate-level logic with no microcoding. So anyone with time to spare could copy that. It's not a trivial job, and it's probably more time than it's worth. But it's not unimaginably hard either.
There's no obvious relationship at all between (say) Python and the gate-level internals of any mainstream modern CPU. There are at least four (five? six?) levels of abstractions between them.
It's useful to build a generic gate-level processor to have some notional idea of what a computer is. And of course it's essential if you go into processor design. But µArch details are a graduate-level topic and not something most developers need to worry about.
The software manufacturing industry could do with some more silicon sympathy.
See: Wirth's Law.
These are still orthogonal concepts. First of all, it's all about cost: if the operational costs of running a piece software over the lifetime of said software are significantly lower than the cost of optimisation, there's nothing to be gained from doing the latter.
Developer time is more expensive than a faster CPU, additional RAM or slightly higher power usage. Back in the day, the iron was expensive and developer time was cheap. Today it's the other way around, so saving on development time is more important than optimising for specific hardware.
Hardware-level optimisation becomes especially bogus if your deployment target is data centres - you often don't even know the deployment target beforehand (could be an ARM CPU, could be an x86 CPU). With many modern SoCs (see the M1), it's even impossible to optimise at that level, since you don't even get the required hardware specs and simply using Apple's libraries will get the best results.
So my argument still stands: there's litte benefit in general from going into such detail. Feel free to disagree, but developments like the Go language, SoCs, and GPGPU compute seem to point another direction.
> It is to learn how to build a computer.
And how does that translate to actual hardware then? Very poorly still. The fact is that unless you work with certain embedded systems, you never get close enough to the hardware to benefit from this.
This is time better spent on learning how to use your tools and to learn how to benchmark and optimise based on algorithms and data structures instead, because that's where the inefficiencies start.
Besides, most programming languages are so far removed from the hardware, that there's absolutely nothing you can do to optimise (JS, Python, Go, Java, C#, Haskell, LISP, etc.).
Languages like Python made it much easier to program but didn’t put as much thought into performance. I think the future of computing will be in languages that manage to be pleasant to write like Python while still exploiting low level hardware features. Rust, which is like C++ that doesn’t suck, and Julia, which is like Python with cleaned up semantics to allow easier compilation, come to mind. The economics of a few people developing high performance languages that everyone can use just makes too much sense. More cloud computing may be cheaper than more devs, but it still isn’t cheap in the absolute sense.
> The economics of a few people developing high performance languages that everyone can use just makes too much sense
I agree: high performance is the job of a _few_ people. It doesn't hurt to know basics for it for everybody else, but even then... that's just one area out of many a dev could dive into. Maybe security or virtualisation or OS programming or whatever would be just as useful or more. My point is that we can't pick a random subfield of software engineering and say "everybody should be skilled at that"
My college physics curriculum included building a 4 bit minicomputer from TTL (in the early 80s). While we were given the design, we still had to understand it in order to make it work, because nobody's machine ever came up on the first try.
Do you (or did you) write software that people find useful? That's what matters most.
The space for building 6502-era CPUs is saturated; let's move on to the PowerPC or Pentium Pro, please.
https://news.ycombinator.com/item?id=5353198
Visual 6502 made me understand my Commodore 64 in an unexpected deep level. I experienced epiphany and bliss: I can begin to understand how computing works from GraphQL down to electrons.
Note: The site's a little underpowered, so posting a link here may slow it down :)
I've also seen ones that can be programmed in C, BASIC, and even Pascal. Again, magnets for my disposable income.
The closest thing I know of is HP 48 - not Forth, but quite Forth-like, and it definitely tought me a thing or two.
I was involved in embedded design in the late 80s/early 90s and as soon as Flash memory became available, we switched all our product lines over within a year, even though the cost was still 10x higher. UV erasable EPROM was THAT much of a pain to deal with.
It blows my mind that the author was still using EPROM after 2000.
HN's fascination with Lisp and Forth is perfectly understandable. Combined with DIY hardware, this sounds like a sweet spot for intellectual... cough... stimulation.