8086 Segmented Memory was a good idea
owl.billpg.com
8086 Segmented Memory was a good idea
1–10 of 150 posts
Re: 8086 Segmented Memory was a good idea
#2No
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)
Re: 8086 Segmented Memory was a good idea
#3No 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 worke…
Indeed, I say as much at the end.
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.
Re: 8086 Segmented Memory was a good idea
#4No 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 worke…
> In hindsight maybe a binary level translator from 8080 to 8086 would have worked better (and be simple enough)
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.
Re: 8086 Segmented Memory was a good idea
#5It might have worked better if x86 had general-purpose registers where every register could work as a segment. Or maybe just many more segment registers. But with only two data segment registers to play with and quite cubersome (and slow!) loads, most software just chose not to bother.
Re: 8086 Segmented Memory was a good idea
#6Google's native client (NaCl) even used it on 32-bit x86...
Segmented memory (on hardware that supported segment permissions) was used to good effect in Multics as well.
Re: 8086 Segmented Memory was a good idea
#7No 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 worke…
It's not all that different from the memory pages we have today, except that the 'segment' addressing has become a lot more complex under the hood (multi-level page tables) and a lot simpler at the surface (by merging the 'segment-' and page-address bits into a single virtual address).
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.
Re: 8086 Segmented Memory was a good idea
#8What is the difference between the segmentation model used by Intel and the banking model used by a lot of consoles? I've worked with the code of a couple of NES and GBC games, and while banking could be annoying, I never saw it as a particularly difficult model to follow and use. It did require more planning for the various functionality, but it wasn't even the most complex or difficult thing about developing for consoles.
Re: 8086 Segmented Memory was a good idea
#9No 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 worke…
Indeed, I say as much at the end. 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 wo…
> Also it's the year ~1980 and we're limited to the technology of the age.
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).
Re: 8086 Segmented Memory was a good idea
#10No 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 worke…
The 8086 was a stopgap measure to accommodate the fact the iAPX432 was in the middle of turning into the disaster it did. Given the engineering resources and timelines involved in the 8086, it wasn't a bad compromise approach.
> 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.)