I think once you move from early fantasy CPUs to early CPUs in production such as 80286, the complexity immediately moves up drastically. IIRC it involves at least memory segmentation, protected mode (MMU).
True enough, but having designed a “fantasy cpu” gives you a better frame of reference for understanding the more complex features of a cpu (privilege levels, memory segmentation, virtual addresses, cache hierarchy, etc.)
I often feel like those who haven’t done the exercise of understanding the ISA of a “fantasy cpu” have a really hard time understanding those more advanced features.
I guess all I am saying is that learning the “fantasy cpu” still has value even if everything else in the real world is more complex.
I've been doing some planning for a 24-bit fantasy CPU, my plan is to make it pretty baroque. For instance it has some instructions to do things like unpack UTF-8 strings into chars, do alpha compositing, etc. The CPU part looks like a strange mainframe that didn't quite get built into the 1970s and it is coupled to a video system that would make a Neo-Geo blush.
“Neo Geo[a] is a brand of video game hardware developed by SNK.
It was launched with the Neo Geo, an arcade system (called MVS) with a home console counterpart (AES). Games on the Neo Geo (MVS and AES) were well received and it spawned several long-running and critically acclaimed series, mostly 2D fighters. Later, SNK released the Neo Geo CD, a more cost-effective console with games released on compact discs, which was met with limited success. A new arcade system, Hyper Neo Geo 64, was released in 1997, but it did not fare well. SNK also released a handheld console under the brand, the Neo Geo Pocket, which was quickly succeeded by the Neo Geo Pocket Color, which have been given praise despite its short lifetime.
SNK encountered various legal and financial issues resulting in a sale of the company in 2001. Despite that, the original Neo Geo arcade and console continued receiving new games under new ownership until 2004. The Neo Geo brand was revived in 2012 with the release of the Neo Geo X[1] handheld. Since then, a number of other Neo Geo products have been released based on the original Neo Geo.”
I just realized that people like me that know all about the Neo Geo are actually in the minority in the world. It's easy to forget what is and isn't common knowledge.
Forget advanced features... Without understanding a CPU it's easy to never really understand pointers, and without pointers, it's hard to understand lots of data structures.
I was easily 12 months ahead of other students in my CS education because I learned 6502 assembly in high school. I wish all CS courses started with "make a VM".
I don’t get this take. Is it so hard to understand that a computer operates on a giant array of bytes?
I think the hard thing to understand is that C’s pointer syntax is backwards (usage follows declaration is weird).
I also think understanding how arrays silently decay to pointers and how pointer arithmetic works in C is hard: ptr+1 is not address+1, but address+sizeof(*ptr)!
Pointers are not hard. C is just confusing, but happens to be the lingua franca for “high level” assembly.
> Is it so hard to understand that a computer operates on a giant array of bytes?
Beginner programming languages universally (since BASIC and Pascal) were designed to hide this fact. There's nothing in a beginning Python course that explains the true nature of computers. You learn about syntax, semantics, namespaces, data structures and libraries. But there's nothing that says, "a computer is endlessly incrementing a counter and executing what it finds where the counter points". And this is probably partly because of "go-to considered harmful", which posited that a lack of control flow (which is a fundamental fact of how computers actually work) is harmful to reasoning about programs.
It's probably objectively true. But a lack of go-to also restricts people from seeing the fundamental truth of the indistinguishable nature of data and instructions in the Von Neumann architecture. Which may also make it difficult to explain GPU computing to students (because it must be understood by contrasting it with Von Neumann architecture).
This is very true. I had tried learning C multiple times but pointers were always kind of hard. I kind of understood them but not really. I later spent a lot of time making an OS in assembly for my homebrew 6502 computer, and after that pointers made so much sense. It actually took me a little while to realize that these addresses I was passing around were pointers, and I had started to understand them without realizing it.
Or you could pick the 68000 which is easier to emulate than a 286 because it was 'properly designed' (and not a stopgap solution like the x86 line until the 386 arrived).
the 80286 has its own problems/inessential complexity
if you look at this from the riscv angle, moving from "u-mode only vm that doesn't use paging under the hood" to "u+s-mode vm with sv39" isn't an enormous jump in complexity imo
i think i might teach it starting as like, "sv21" (page tables aren't nested), then pose real sv39 and the tree structure as the solution to making a sparse mapping over 512GiB
then moving on to the idea of having a TLB is simple, especially if students have already been introduced to hashtables
may be the best realization. You can almost run a real operating system on that chip in the sense of a 24 bit supervisor that could run multiple 16 bit processes (if you could get CP/M to run you have one heck of a userspace) Unfortunately you can't trap the instruction that switches back to 24 bit mode.
Would be nice too if a 24 bit supervisor could contain a 24 bit application, that requires some kind of memory management and I'd imagine something a little lighter weight than the usual paging system, say something that maps (0..N) in logical space to (i+0..i+N) in physical address space. I like the "access register" concept
but would probably have a small number of memory banks such as 16 or 64. In a load-store architecture it doesn't seem like much of a burden to add a bank id to stores and loads. In return you get not just more RAM but also separation of code and data, video memory, file mmap(ing) and such.
What bugs me is how to control the mapping of memory banks to physical memory, on one hand you want the supervisor in charge so it can be used for memory protection, on the other hand some programming techniques would want the speed of changing the memory banks from user space.
The 80286 was a turkey because it didn't meet the minimal viable product level of being a target for a 24-bit OS that could virtualize DOS applications. It was already crazy fast and became affordable pretty quickly but it seemed tragic that it couldn't do that.
> The 80286 was a turkey because it didn't meet the minimal viable product level of being a target for a 24-bit OS that could virtualize DOS applications. It was already crazy fast and became affordable pretty quickly but it seemed tragic that it couldn't do that.
That's mainly because it was designed before the IBM PC was a success and backwards compatibility with DOS applications important.
I took a different approach by just making an FPGA-based multi-core Z80 setup. One core is dedicated to running 'supervisor' CP/NET server, and all of the applications run on CP/NET clients and can run normal CP/M software. I built a 16-core version of this, and each CPU gets its own dedicated 'terminal' window, with all of the windowing handled by the display hardware (and ultimately controlled by the supervisor CPU). It's a fun 'what-if' architecture that works way better than one might expect in practice. It would have made an amazing mid-to-late 1980s machine.
Even better than that was an Z280 which did have a proper user/supervisor mode and simple MMU. Really reminiscent of a PDP-11 in terms of supervisor state, just strapped to a z80 instruction set otherwise. Also added a nice SP relative load to the instruction set.
The mostly redundant memory segmentation features that modern OS do not care or use anymore.
If OS fully utilizes memory segmentation it can be the most secure OS and makes borrow checker languages like Rust becomes unnecessary since not unlike Rust it can mitigates data races and race conditions (better at the latter).
This can considerably reduce developers' cognitive load or overload [1]. It also can contribute towards more secure computing and containers can be made as secure as VMs.
Someone can probably propose a new memory segmentation extension to the Linux kernel in the similar manner of real-time Linux. But again it can takes 20 years to be accepted into the mainline Linux kernel [2].
There are plenty of real CPUs that are useful in the real world but are much simpler than a 286.... 8 bit RISC microcontrollers like Atmel AVRs for example. I've done a small amount of programming for those in assembly, and they are not a whole lot more complex than the 'toy' design I used for the class.
