3 ms·

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 h

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

PaulHoule 2y ago
Sometimes I dream of a 24-bit generation of computers (in terms of address space and the space of index math) of which https://en.wikipedia.org/wiki/Zilog_eZ80 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 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.
- kazinator 2y ago
  Also PIC24 family of μcontrollers.
- Narishma 2y ago
  > 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.
- monocasa 2y ago
  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.
- fentonc 2y ago
  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.

PaulHoule 2y ago

Sometimes I dream of a 24-bit generation of computers (in terms of address space and the space of index math) of which https://en.wikipedia.org/wiki/Zilog_eZ80 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 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.

kazinator 2y ago
Also PIC24 family of μcontrollers.
Narishma 2y ago
> 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.
monocasa 2y ago
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.
fentonc 2y ago
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.