Is there a good microprocessor with 24-bit addressing?
The original IBM 360 had a 24-bit address space.
https://en.wikipedia.org/wiki/IBM_System/360
Microprocessors of the golden age of home computing (Apple ][, TRS-80, Commodore 64, CP/M machines based on the 8080 and Z80) usually had a 16-bit address space, the 8086/8088 was a bit of an exception because it had a segmentation scheme to access 1 MB. (People thought it was awkward but I liked programming it in assembly language and Turbo Pascal) I remember the PDP-11 minicomputer having a 16-bit address space for user programs as well, the machine as a whole could be a lot bigger but an individual logged into it had access to a virtual "home computer" that ran BASIC and all.
24-bit was a natural evolution and by the late 1980s you started to see 24-bit chips like the 80286 (PC AT) the 65C816 (Apple IIgs, Ninteno SNES), the eZ80 and such. Even the bigger AVR8 processors (I love AVR8 assembly) can have more than 64kb of program memory (flash, read-only in operation) so they use 24-bit addresses for program memory.
In my mind we never saw a product of this generation that really took advantage of the address space, the 80286 in particular was called "brain damaged" by Bill Gates and operating systems struggled to exploit it. My take is that most of the chips of that generation were flawed in one way or another and were pretty quickly washed away by 32-bit machines when they became affordable in the early 1990s.
For an example of the difficulties, there is this project to make a retrocomputer that is a bit better than anything we had in the 1980s,
https://www.youtube.com/watch?v=0oYcu43N-lw
they are using the 65C816 but not taking advantage of the 24-bit nature. Instead there is a simple bank switching scheme which I think they thought would be easier to program and probably faster. The 65C816 just doesn't have enough registers and addressing modes for it to be really easy to work with far pointers.
So my question is, if I am a hobbyist who wants to revive the 24-bit generation and I want to have easy access to a 16MB address space, is there some CPU better that doesn't suck? I'd be happy with a CPU that doesn't have virtual memory or other facilities for an advanced operating system (write everything in "real mode") but something that supports an OS would be interesting too. Any ideas?
I take it you are looking for a 24 bit processor with a flat addressing scheme instead of bank switching?
Basically.
I want long pointers, but I also appreciate mechanisms like a movable zero page or segmentation that would speed up or improve code density if you are doing as lot of operations in "local" memory.
It sounds like you're talking about address width. You could say that the early Macintosh was a 24-bit machine, because the Motorola 68000 had 32-bit pointers but only 24 address lines, so the top byte could be used for something else, and it often was.
When new Macs came out with more memory, using the 68020 that had all 32 address lines, a lot of software broke and had to be updated to be "32 bit clean."
I don't remember if Amiga and Atari ST programs would also take advantage of addresses only being 24 bits, but it wouldn't surprise me.
The 68k chip came out in 1979 but was expensive at first, which I assume is the main reason these other chips were used, along with compatibility with 8-bit machines. So I don't see those 24-bit machines as a natural evolution but rather a cost-cutting option. Since that's not an issue now, I'm not sure what you're looking for in a processor?
I am interested in hobby computing, particularly I enjoy the Arduino and assembly language programming with the AVR8.
I like how lean the AVR8 is, I like having a huge register file of 8-bit registers and a system size where using 3 bytes (in RAM, registers, or ROM) to handle 24 bits is a substantial win over 4 bytes if you don’t need numbers that large.
One could make the case that modern architectures have a lot of bloat from the memory management system, translation lookaside buffers, operating systems (no innovation possible there because you’ll want to take your POSIX user space with you), etc. It’s nice to think about making a fresh start.
There is something silly about it though. The Commander x16 is a beautiful machine but it costs about what 8-bit machines cost early in the 8-bit era and doesn’t really compete with the Raspberry Pi on price. They might eventually come out with an ASIC version but then it’s basically a low-performance Raspberry Pi. Still if you are making a low number of devices it is easier than ever to build a single board computer based on some random old CPU and you can afford to load it with more RAM than possible back in the day.
I also find it fun to speculate about what could have been. The 286 absolutely crushed all the other microcomputers I could afford in the late 1980s, I remember the time I had to develop some software for CP/M and found it could emulate the Z80 much faster than any real Z80. The MS-DOS market really would have loved a multitasking or task switching system but the 286 just wasn’t capable, had Intel really understood the need for a “virtual x86” and worked out a cheap way to provide it, the industry might have taken a different trajectory than it did. You could also make the case that the 68k Mac was a mistake given the multiple near-death experiences the Mac had when it was forced to switch architecture. Maybe the Apple //gs could have been out a few years before it was and taken the place of the Mac, etc.
Yeah, it seems like a fun nostalgia thing.
It sounds like you might want a processor with an 8-bit data bus and a 24-bit address bus? I think that makes sense, though it means 3 loads or stores per address. It seems like a fun fantasy processor.
The Motorola 68k has a 16-bit data bus and 24-bit address bus, which means a minimum 1.5 loads per address and that rounds up to 2. So that's where having 32-bit pointers where only 24 bits are used comes from. I think 24-bit pointers only make sense if the data bus is either 8 bits or 24 bits.
Looks like a 286 had a 16-bit data bus and 24-bit address bus just like a 68k, but only 16-bit registers due to compatibility with the 8086. So a full address couldn't fit in a register, resulting in weirdness.
When I was in college I took a EE course where the big class project was to make an 8-bit processor using an FPGA. These days you could probably do a 286-class processor (at least) with an FPGA and design it however you like? In theory, anyway.
Writing an emulator would probably be easier, though. Maybe a way to "start over" would be to run an emulator for whatever fantasy processor you like on a Raspberry Pi Pico? It's $4 so I don't see a point in using anything less powerful. If that's not fast enough, a Teensy 4.1 at around $32 seems like the logical upgrade.
There are a few paths. One is to look at parts you can get from Jameco (eZ80?) and find something that is good enough and build or buy an SBC.
You can get to a 24-bit index register by appending 8 bits to a 16 bit register or maybe something like the 8086 segmentation model where you multiply the segment address by 256 instead of 16. (All kinds of architectures of that era have various schemes that combine multiple registers into one.)
To deal with the software problem it would be appealing to be compatible with some existing architecture, for instance with the Z80 you could run software written for CP/M you could get away with locking down the “segment” registers in “legacy mode” and get out of it with a software interrupt. Instruction prefixes could choose the segment that the next instruction addresses in like the 8086 but it could be made cleaner. (I think also a segmentation model could be a lot simpler than a paging model). The Z80 has quite a few multibyte instructions with the second byte unused but I don’t think there are any first bytes free.
If you are running in emulation you can get away with crazy long instructions as you’ll really have the fetching power of a modern pipelined and superscalar processor behind you and the emulator doesn’t really get more complex.
Implemented on an FPGA or other real hardware it seems like a big hassle to support longer instructions, you are going to waste memory bandwidth loading a instructions (some of why I like the Harvard AVR8.). That puts a lot of pressure to go in a pipelined/superscalar direction. An FPGA implementation of a 6502-class processor or even an AVR-8 is not so bad. One of those big steps in the 1980s though were systems that could hide memory latency and those add to the transistor count and other complexity big time. Some architectures made that transition and others didn’t.
I only do through-hole soldering and not very well so I'd rather buy a microprocessor already soldered to a board.
I think these weird addressing modes became less popular as people started using compilers more instead of assembly and through the influence of RISC processors.
A 16-bit register only lets you address 64k of memory which would result in weird, frustrating limits on things like the lengths of strings and therefore documents, or alternately using slower workarounds and it's not like they had a lot of performance to spare. It's maybe not the worst thing for a video game but would suck for a complex office suite or graphical OS. And I'd guess that's why Bill Gates complained about the 286.
The Mac didn't have to deal with that, but it was very expensive at first.
In the 1980 people were excited about the 68k series chip that was famously used in the early Macintosh but Motorola gave up on the 68k line by 1990 and committed to the PowerPC RISC chips that Apple used for a while and IBM still uses on the server. People were excited by the clean programming model that would let you address lots of data but I think 68k machines were a bit of a disappointment and by the early 1990s every company that made machines based on them either went out of business (Sinclair, Atari, Amiga, …) or switched to another architecture (HP, Sun, Apple, …). I’d love to know the inside story of what happened to the 68k.
In the DOS age a compiler usually had several “memory models” available, a small program could just use a single 64k segment for everything, you could have separate code and data segments and various other models. One thing that was amazing about C, and why it caught on in the 1980s, was that code from minicomputers (say the game Nethack) could frequently be ported to run on DOS without a lot of trouble, and it even scaled down to 8-bitters like the TRS-80 Color Computer and CP/M machines. (I’m a little amazed at how well C scales down to the AVR8)
Unlimited length strings are still controversial today, they set you up for denial-of-service attacks and various corner cases for performance. Once you get to really enormous memory sizes (say 1 TB+) it starts getting questionable if you want to lay out arrays in a linear manner because of how it interacts with the NUMA nature of big modern machines, also the whole paging and TLB mechanism is going to get more cumbersome as machines get bigger.
With the old 8086 for instance a runtime for a language like LISP might have a hierarchical organization such that an “object” is pointed to by a 16-bit segment pointer (e.g. points to 16 byte block) but you could then access inside an “object” with a near pointer. Strings limited to 64k aren’t a problem for most applications, except for web browsers, which you aren’t going to fit into that kind of thing.
Some hierarchical approach to memory management also makes sense today in that you really do want to build structures that play well with the cache hierarchy.
It seems like you’re going out of your way to defend a bad situation out of misplaced nostalgia. Porting C programs between early personal computers was easier than porting assembly and that was important. But it did require a lot of messing with macro definitions and other obscure nonsense. Anything that used graphics or sound probably required something close to a full rewrite. Portability is much better today, even in C, and other languages make it routine.
The situation for DOS didn’t help. Segments as a way of implementing protected memory and preventing overruns is a possibly useful idea, but using them as a way to keep using 16-bit registers resulted in a pile of hacks.
Segment pointers might be useful for medium-sized objects provided that 16-byte alignment doesn’t waste too much space, but that’s a pretty severe and arbitrary design restriction. I don’t see how it would be any use for Lisp? You could put two 32-bit pointers in an 8-byte cell and that cuts memory use in half. Meanwhile, a far pointer is in no way better than a 32-bit pointer. It takes the same space and is harder to use.
Sure, setting some limits on the sizes of text fields can be useful. It’s often done in databases, though often it’s not well thought out. Deciding what to set a varchar’s limit to is often quite difficult to judge, because it requires knowing a lot more about users than you generally know when designing a database schema. I would usually be very generous so it doesn’t come up for anyone other than an attacker and have one size for all single-line text fields and another for all text boxes. But I never got any feedback on whether I got it right; it was just guesswork.
Also, that doesn’t mean 64k or less would be the right limit. It’s generous for a single line of text and probably fine for a Tildes post, but the average novel is around 100k words. Other document types like images and audio take a lot more room, let alone video. Limits that low would certainly be a problem for a text editor or office suite.
The 386 put an end to all that nonsense and good riddance.
(Setting limits on text fields reminds me of setting a timeout for when an operation should fail; sometimes you need one but it’s annoying to pick one. What if the user is willing to wait longer than the arbitrary number you picked for something that’s important to them? A user-friendly way is a progress bar and a cancel button, but that doesn’t help for unattended operations.)
I'll point to this one which just came up in my feed
https://www.cs.cornell.edu/~asampson/blog/flattening.html
of how alternatives to flat pointers can be a win.
Yeah, it’s a good article. (I just posted it here.) It doesn’t cover wasted space when your tree nodes are varying sizes, though.
Some details are swept under the rug that would reappear at the assembly level. An array index is multiplied by the cell size to get the actual memory location. More address registers saves on multiplies since often they can become adds. Hardware that’s more flexible about cell alignment (more possible cell sizes) reduces wasted space.
You could think of the segmented architecture on a 286 as an array implementation that’s pretty limited on cell sizes and number of elements in an array when compared to being able to do multiplies and adds on full-size address registers. Even today, it sometimes makes sense to save memory in pointers stored in data structures, but the address registers themselves are full-width.