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).
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.
Walking before running and all that.
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.”
— Wikipedia
Seems to be from about 30 years ago in the 1990s.
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 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.
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).
A wonderfully different early CPU with plenty of existing software is the https://en.wikipedia.org/wiki/RCA_1802 which was a target of the https://en.wikipedia.org/wiki/CHIP-8 interpreter.
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
https://en.wikipedia.org/wiki/Zilog_eZ80
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
https://en.wikipedia.org/wiki/Access_register
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.
That's mainly because it was designed before the IBM PC was a success and backwards compatibility with DOS applications important.
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].
[1] Cognitive load is what matters:
https://news.ycombinator.com/item?id=42489645
[2] 20 years later, real-time Linux makes it to the kernel: