Posted by billpg 2 days ago
How is that compatible with an array and a simple implementation of the index operator?
This was a problem.
No, it wasn't
It's the "great idea" that sounds great 5 min in and horrible 10min afterwards
You know, kinda like using null as a string end character
But more importantly it kept the x86 world for too long in that dead end that was 8086 mode programming
"Oh if developers would just..." They won't. They haven't. And they will not ever.
In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough)
> But more importantly it kept the x86 world for too long in that dead end that was 8086 mode programming > > "Oh if developers would just..." They won't. They haven't. And they will not ever.
8086 real mode programming in the mainstream lasted from 1981 until 1991 or so. The last 35 years have 32-bit (and later 64-bit) flat model addressing with pages for the most part. Seems like a reasonable transition period, really.
> In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough)
Part of the reason they liked the segmented model is that it was possible to set the segments to the same value and then ignore them entirely. That gave a programming model for the 8086 that was sufficiently close to the 8080 that it was possible to use a sort of cross assembler to do something like what you suggest. You could then opt into 8086 specific instructions and segmentation as you needed. (Which took a few years... the first IBM PC's shipped with as little as 16K of RAM.)
But what should Intel have done? They needed a CPU that can run 8080 code but with more memory. Also it's the year ~1980 and we're limited to the technology of the age.
A system with 64k sized windows seems unavoidable.
If you extend the size of the address registers, 8080 code will only run in the first 64k, or require some kind of current window register.
An 8080 mode might have worked but that would have been expensive.
Tbf the Motorola 68000 which was released around the same time (1979) had a proper linear address space with 32-bit address registers (of which 24 bits were wired up).
Also the 8086 was intended as a cheap and temporary stop gap until Intel's "proper" 32-bit CPU architecture was ready for prime time (the doomed iAPX 432).
It would be a piece of trivia today if motorola were not 6 months late which forced IBM in frustration to change tracks to Intel and MS DOS instead (which worked on 8086). That 6 month drlay created WinTel of today.
PS: and segmented memory wasn't all that different from the memory banking used before in 8-bit home computers to address more than 64 KBytes, except that the memory mapping hardware was implemented outside the CPU.
An MMU gives you a flat addressing model. There is no comparison. 8086 segments are rigidly locked to a 64KB window that goes forward in memory 16 bytes for every segment (so segmented address 1234:5678 is linear address $12340 + $5678 = $179B8)
It didn't do this to offer a useful feature like an MMU. It did this to allow code that doesn't know segment registers exist to think they're still running on an 8-bit Z80. What a waste of potential. The 68000 didn't pretend to be a 6502.
The 80286 introduced protected mode with "segment descriptors", but this is well after MMUs existed on other CPUs, it didn't invent virtual memory. Only the 80386 offered a 32-bit flat memory model.
If you want to see something to make you weep, look at the MS-DOS version of unzip. It has to do all kinds of crazy, just to allocate 64KB of RAM and get all 64KB, not 8 bytes less. And it's still locked into a memory access model that will not let it ever address more than 64KB of any one object. It's why MS-DOS was viewed as a toy OS for a toy computer.
#if defined(__TURBOC__) && !defined(OS2)
#include <alloc.h>
/* Turbo C malloc() does not allow dynamic allocation of 64K bytes
* and farmalloc(64K) returns a pointer with an offset of 8, so we
* must fix the pointer. Warning: the pointer must be put back to its
* original form in order to free it, use zcfree().
*/
...
static ptr_table table[MAX_PTR];
/* This table is used to remember the original form of pointers
* to large buffers (64K). Such pointers are normalized with a zero offset.
* Since MSDOS is not a preemptive multitasking OS, this table is not
* protected from concurrent access. This hack doesn't work anyway on
* a protected system like OS/2. Use Microsoft C instead.
*/Many programs written in assembly language used self modifying code back then. It saved RAM and improved performance. All programs that used such trickery would have broken by a binary translator.
Why would someone be popping up in 2026 saying it was awesome? Weird.
* we want to stay 16-bit
* we want to make porting extremely easy
* we want to make gradual upgrading of people's programs to >64K easy
* we want to work well with really small memories (so don't force people to use fat pointers all the time)
* we don't want the typical (or max non-redundant) instruction to get too long
* we don't want an MMU
* we don't want complicated bank switching
* we don't want long carry chains for all address generations
* -- but we still want a gigantic address space (for the time it was designed)!Imagine if you could have done something like this:
add si, some-delta
adsc es, 0
ADSC (add with segment carry) would do:
segreg := segreg + imm + 1000h (if carry)
segreg := segreg + imm (no carry)
ADSC could have been adapted for the 286 with ease, as long as a specific layout of the segment descriptor tables was mandated (probably with 10h instead of 1000h in protected mode).
Edited slightly for clarity (ofs => imm). A normalizing instruction would be harder to do right for the 286 because you don't want to spend too many slots in the descriptor table(s) for a single memory object.
Segmented memory (on hardware that supported segment permissions) was used to good effect in Multics as well.
It was just a hack. Hack to delay migration to 32 bit architecture. Effective one, but hack nonetheless
When I was learning C, we did things at a reasonably low level. I was learning data structures, and building things like binary trees out of things like structs, and the structs were fixed-sized memory blocks holding pointers to regions of memory which were either more structs or data fields. All reasonable stuff. But we weren't writing for a particular machine. We were writing for the idea of a machine, and part of that idea was that the machine had a flat memory model. This really struck me when I compiled my homework (parse some data into a tree) on the departmental SunOS server, and it worked fine, and then took it home and compiled it with Borland C for DOS on my 386 and it segfaulted on the same data. That was when I learned to hate segmented memory, but looking back, it seems to me that I learned the wrong lesson.
I learned to write software for a lowish-level model of an idealized computer. The generation before me was always writing software for a specific computer, consisting of a specific set of hardware. The software was always the goal, but the nature of the task was defined by the hardware. Things like memory segmentation were facts about the hardware, and the available hardware varied widely at the time in a way modern hardware doesn't, really, except maybe in the embedded space.
Not to do a "The Amiga was ahead of its time" thing but as a reminder, 68000 has a flat 24-bit address.
The segment thing and the convoluted different pointer math caused real gymnastics if you ever had data bigger than 64k... such as images.
I always thought of the segments as windows of 64k but moving between those windows, esp with the limited register set, required some real mental gymnastics.