6 ms·

I seem to recall at the time that flat memory was self evidently a better idea. It's not like people were sitting around going "gee I can't think of any better

I seem to recall at the time that flat memory was self evidently a better idea. It's not like people were sitting around going "gee I can't think of any better way to do memory addressing that this" until some genius suggests "how about flat?!?!?" Everyone knew flat was best but were stuck with 8086 crap.

PaulHoule 4mo ago
Personally I enjoyed writing assembly with segments. You can have 64k of code, 64k of data and 64k of stack without trying. So long as no individual data structure is larger than 64k there is no essential difficulty working with 16 bit pointers. When I think back I think it would be fun to have a hierarchical structure where composite data structures (think an array or hash map) are referred to with a pointer that goes into the segment register and you index inside a data structure with a regular pointer.
- trollbridge 4mo ago
  Lots of 8086 code was written that way. You’d use the segment register on paragraph alignment and basically take advantage of the << 4 + logic. This code was a nightmare to port to protected mode 80286 so it went away by the Windows 3.1 era.
  - PaulHoule 4mo ago
    I went from a 6809-based Color Computer 3 circa 1987 to a 80286. I am kicking myself today because my Uncle Bob told me the job that paid me $1,200 to get a new machine created upwards of $60,000 of value so I could have asked for enough to get a 386! I was told not to waste any time with 80286 protected mode by all the experts I talked to. I can't complain a lot because that 80286 was crazy fast. Fast enough that when I got another job to develop some software for a teacher at my school I was able to run a Z80 emulator to develop for CP/M and get performance several times better than any real Z80! I loved programming it too, the 286 had some 16-bit data paths that the 8086 didn't have which I took advantage of in assembly and in copy/move/zero routines that I used with Turbo Pascal which I thought was a much nicer language to C but when I got to college I switched to C because it was portable to the Sun 68k and later SPARC machines we had.
KellyCriterion 4mo ago
-- Everyone knew flat was best but were stuck with 8086 crap.-- This! Thats one of the most interesting things to me: Actually very often in the IT-world, the worst competitor won the race while better solutions were known and available: Microsoft, Intel etc. Esp. that MS won for decades while making mainly a very bad OS, though they have some good enterprise products. How would the world look, if Unix/BSD would have won this race?
- wewewedxfgdf 4mo ago
  Being technically best has long been known to not be correlated to market success in the way that makes logical sense to technical people who feel confused about this.
- Ekaros 4mo ago
  I really wonder if Unix is best we can do. Or is it also worst? So in the end two of the worst options won. It did make sense back in time. But could it have been replaced with something better later?
  - wewewedxfgdf 4mo ago
    >> two of the worst options won What do you mean, which are the two? Sure, Windows is crappy by Linus and MacOS? They are both awesome.
    - simiones 4mo ago
      There are many crappy design decisions in Unix, Posix, Linux, MacOS, that have been known and worked around for decades (see the Unix Hater's Handbook). One example would be async IO, which has been famously bad in Unix, and Linux alone has tried 2 different generations of solutions - with the newer one, io_uring, being suspiciously similar to Windows' decades old IOCP. Fork/exec is infamous as a needlessly complex process creation API, requiring huge effort in the kernel just to handle the most common case of simply launching a new process. The traditional Unix security paradigm of simple user based file permissions is extremely weak and has required numerous solutions on top to handle realistic security scenarios - e.g. to protect a user's files from being tampered in unexpected ways by a process launched by that user (SELinux, jails, namespaces, etc). I agree that Windows is crappy, but that doesn't mean that Linux and MacOS aren't also crappy in their own ways (not to mention iOS, Android).
Someone 4mo ago
Not entirely self-evidently. Position independent code was slower at the time and avoiding having to patching function addresses at load time is a net win. More importantly, there’s backwards compatibility. By the time the 8086 came out, people had spent serious money on getting binary-only software (WordStar cost hundreds of dollars, for example). “Buy this computer, and you can keep running the software you paid for, but faster” was a good selling point.
- rickas 4mo ago
  I wonder why couldn't Intel simply introduce single 'offset' register for apps ported from 8080, and make all other registers 20-24bit. Why bother with 4 different registers and all that segmentation nightmare?
  - trollbridge 4mo ago
    Lots of benefits to a word size a power of 2. Very few benefits to a clunky 24 or 20 bit word size; now it costs more and is a bizarre boutique architecture in a world where it needs to compete with 8 bit Z80s and 6502s.
  - peterfirefly 4mo ago
    A single one would require a ported app to understand that it worked with bigger registers in order to take advantage of the bigger address space. Some really old computers did work like that, but to allow several apps to coexist in memory, not to give each app more addressable memory. The segment register solution does both almost for free in most cases. Code gets a segment, data gets a segment, stack gets a segment... and you are free to use all of memory if you bother to use the ES register. In many cases, that could be isolated to a small piece of the program so that was also quite cheap. As someone who wrote code in assembler, Pascal, and C for those machines: it wasn't at all a nightmare. It was quite easy and simple.
alerighi 4mo ago
Except than later we returned to a sort-of segmented memory. That is of course paging, our programs allocates pages of memory that are a fixed size (4096 bytes) and are arranged in memory or in swap space how the OS decides. We just have the illusion of a "flat" memory model, but it's not really flat, the CPU and the operating system does an important job in translating our flat memory model in something that is not flat at all. All that address translation work could have been avoided if we accepted to not have a flat memory model and be aware that our memory is divided in pages. Basically we are doing in hardware the job of managing a non flat memory space that the programmer, or well, the compiler (or these days you would say the AI agent) could probably to better because it knows how to allocate things to avoid being them on page boundaries, and all of this to give the illusion to the programmer that it's working with a flat memory (except when it does something wrong and gets a segmentation fault, that, as the name suggests, is an hint that at the end the memory is not really flat).
- bluGill 4mo ago
  In turn though, the thinking needed to handle non-flat memory is a complexity that most programmers cannot handle - and even those who could probably should spend their brain power on the complex parts of their program not managing memory. Best to leave that hard part to a few experts instead of make everyone understand it. The above is very similar to the argument that you should use a garbage collected langauge.
  - trollbridge 4mo ago
    Anyone writing an algorithm that needs to be high speed has to start thinking about caches and so forth. So it’s not exactly obsolete. Back in 1980 most programs were being written in interpreted languages that did all the hard work of memory for you - just like today.
- deleted 4mo ago
  [deleted]
- wang_li 4mo ago
  Paging is not part of the CPU architecture. On CPUs of the time the MMU that brought paging to the party often was a completely separate peripheral that the CPU interacted with to gate access to RAM. By contrast segments are an integral part of the CPU instruction set and your code either has to limit itself to 64KB or your application had to be aware of and include logic to manage segments. As an aside, the memory model is flat, it's just not physically linear when implementing virtual memory addressing.
phkahler 4mo ago
I was drooling over the MC68000. I had a pre-release reference manual from 1979 and it was the most awesome chip around. Atari and Commodore and Apple used it after their 6502 systems. Arcade games used it after their 6502 and 6809 days. The only reason x86 became popular was because IBM put it in the PC - not for any technical reasons.
- trollbridge 4mo ago
  A 68k was roughly double the cost of an 8086, plus the additional cost for the rest of the supporting chips. The PC was intended to be cheap and was competing with 8 bit machines. Being 16/20 bit made it already high end. If you wanted 24 or 32 bit, IBM had many other machines to sell you. Or you could just buy a VAX.
ThrowawayR2 4mo ago
Flat memory was a better idea but it wasn't a cheaper idea, and cheaper beats good. A casual Googling shows a price of $2,880 for a IBM PC in ~1982 dollars versus $8,900 for a Sun Microsystems Sun-1 with a MC68000.
- amiga386 4mo ago
  That was just Sun's market segment. Also from a casual Google, an IBM PC launched in 1985 (picking the XT 5160-078 as an example) was around $4,995 at launch. Compare that to two 68000-based computers also launched in 1985: the Amiga 1000 launched at $1,295 and the Atari 520ST launched at $600. These computer system prices - Sun, IBM, Commodore, Atari - came from the market segments the manufacturers aimed to sell to, rather than a cost saving enabled by cumbersome memory models. The cumbersome memory model is just a historical accident; the 8086 designers wanted 8080 backwards compatibility so they could sell to former 8080 users, IBM did not require this. IBM would've picked the 68000 had it been "production ready" at the time, they did not reject flat memory on cost grounds!
  - dfe 4mo ago
    Are you sure IBM didn't care about 8080 compatibility? The PC was released in August 1981, a full 4 years before any of the other machines you speak of. That XT 5160-078 you speak of is a cost-reduced model with no hard drive from IBM, allowing dealers to install a compatible hard drive from a different supplier. By 1985, the PC AT (286) had already been out since August 1984. And the original XT was October of 1983. And the XT itself is literally the same as a PC with more expandability: 8 slots instead of 5, beefier PSU, room for a hard drive. It's unclear if IBM or for that matter anyone would have been able to start designing a 68000-based machine and bring it to market by the fall of 1981. Sun brought the Sun 1 to market in May 1982, so about 9 months later, and with a much higher price. And what did the Sun run? UNIX. What did IBM run? Quick ports of the last several years of CP/M software made possible because DOS 1 was specifically designed to implement a CP/M-like API, and the 8086 was specifically designed to allow porting of 8080 assembler code directly to small model 8086 code.
trollbridge 4mo ago
Flat is not necessarily a better idea. In 1978, a 32 bit CPU would be stupidly expensive. The use case for > 64k was to simply have code and data split apart, and also have some MMIO, so basically 192k-256k of addressing needed. Segmentation meant programs could remain essentially 16 bit with all the benefits to that like smaller code size.

PaulHoule 4mo ago

Personally I enjoyed writing assembly with segments. You can have 64k of code, 64k of data and 64k of stack without trying. So long as no individual data structure is larger than 64k there is no essential difficulty working with 16 bit pointers. When I think back I think it would be fun to have a hierarchical structure where composite data structures (think an array or hash map) are referred to with a pointer that goes into the segment register and you index inside a data structure with a regular pointer.

trollbridge 4mo ago
Lots of 8086 code was written that way. You’d use the segment register on paragraph alignment and basically take advantage of the << 4 + logic. This code was a nightmare to port to protected mode 80286 so it went away by the Windows 3.1 era.
- PaulHoule 4mo ago
  I went from a 6809-based Color Computer 3 circa 1987 to a 80286. I am kicking myself today because my Uncle Bob told me the job that paid me $1,200 to get a new machine created upwards of $60,000 of value so I could have asked for enough to get a 386! I was told not to waste any time with 80286 protected mode by all the experts I talked to. I can't complain a lot because that 80286 was crazy fast. Fast enough that when I got another job to develop some software for a teacher at my school I was able to run a Z80 emulator to develop for CP/M and get performance several times better than any real Z80! I loved programming it too, the 286 had some 16-bit data paths that the 8086 didn't have which I took advantage of in assembly and in copy/move/zero routines that I used with Turbo Pascal which I thought was a much nicer language to C but when I got to college I switched to C because it was portable to the Sun 68k and later SPARC machines we had.

KellyCriterion 4mo ago

-- Everyone knew flat was best but were stuck with 8086 crap.-- This! Thats one of the most interesting things to me: Actually very often in the IT-world, the worst competitor won the race while better solutions were known and available: Microsoft, Intel etc. Esp. that MS won for decades while making mainly a very bad OS, though they have some good enterprise products. How would the world look, if Unix/BSD would have won this race?

wewewedxfgdf 4mo ago
Being technically best has long been known to not be correlated to market success in the way that makes logical sense to technical people who feel confused about this.
Ekaros 4mo ago
I really wonder if Unix is best we can do. Or is it also worst? So in the end two of the worst options won. It did make sense back in time. But could it have been replaced with something better later?
- wewewedxfgdf 4mo ago
  >> two of the worst options won What do you mean, which are the two? Sure, Windows is crappy by Linus and MacOS? They are both awesome.
  - simiones 4mo ago
    There are many crappy design decisions in Unix, Posix, Linux, MacOS, that have been known and worked around for decades (see the Unix Hater's Handbook). One example would be async IO, which has been famously bad in Unix, and Linux alone has tried 2 different generations of solutions - with the newer one, io_uring, being suspiciously similar to Windows' decades old IOCP. Fork/exec is infamous as a needlessly complex process creation API, requiring huge effort in the kernel just to handle the most common case of simply launching a new process. The traditional Unix security paradigm of simple user based file permissions is extremely weak and has required numerous solutions on top to handle realistic security scenarios - e.g. to protect a user's files from being tampered in unexpected ways by a process launched by that user (SELinux, jails, namespaces, etc). I agree that Windows is crappy, but that doesn't mean that Linux and MacOS aren't also crappy in their own ways (not to mention iOS, Android).

Someone 4mo ago

Not entirely self-evidently. Position independent code was slower at the time and avoiding having to patching function addresses at load time is a net win. More importantly, there’s backwards compatibility. By the time the 8086 came out, people had spent serious money on getting binary-only software (WordStar cost hundreds of dollars, for example). “Buy this computer, and you can keep running the software you paid for, but faster” was a good selling point.

rickas 4mo ago
I wonder why couldn't Intel simply introduce single 'offset' register for apps ported from 8080, and make all other registers 20-24bit. Why bother with 4 different registers and all that segmentation nightmare?
- trollbridge 4mo ago
  Lots of benefits to a word size a power of 2. Very few benefits to a clunky 24 or 20 bit word size; now it costs more and is a bizarre boutique architecture in a world where it needs to compete with 8 bit Z80s and 6502s.
- peterfirefly 4mo ago
  A single one would require a ported app to understand that it worked with bigger registers in order to take advantage of the bigger address space. Some really old computers did work like that, but to allow several apps to coexist in memory, not to give each app more addressable memory. The segment register solution does both almost for free in most cases. Code gets a segment, data gets a segment, stack gets a segment... and you are free to use all of memory if you bother to use the ES register. In many cases, that could be isolated to a small piece of the program so that was also quite cheap. As someone who wrote code in assembler, Pascal, and C for those machines: it wasn't at all a nightmare. It was quite easy and simple.

alerighi 4mo ago

Except than later we returned to a sort-of segmented memory. That is of course paging, our programs allocates pages of memory that are a fixed size (4096 bytes) and are arranged in memory or in swap space how the OS decides. We just have the illusion of a "flat" memory model, but it's not really flat, the CPU and the operating system does an important job in translating our flat memory model in something that is not flat at all. All that address translation work could have been avoided if we accepted to not have a flat memory model and be aware that our memory is divided in pages. Basically we are doing in hardware the job of managing a non flat memory space that the programmer, or well, the compiler (or these days you would say the AI agent) could probably to better because it knows how to allocate things to avoid being them on page boundaries, and all of this to give the illusion to the programmer that it's working with a flat memory (except when it does something wrong and gets a segmentation fault, that, as the name suggests, is an hint that at the end the memory is not really flat).

bluGill 4mo ago
In turn though, the thinking needed to handle non-flat memory is a complexity that most programmers cannot handle - and even those who could probably should spend their brain power on the complex parts of their program not managing memory. Best to leave that hard part to a few experts instead of make everyone understand it. The above is very similar to the argument that you should use a garbage collected langauge.
- trollbridge 4mo ago
  Anyone writing an algorithm that needs to be high speed has to start thinking about caches and so forth. So it’s not exactly obsolete. Back in 1980 most programs were being written in interpreted languages that did all the hard work of memory for you - just like today.
deleted 4mo ago
[deleted]
wang_li 4mo ago
Paging is not part of the CPU architecture. On CPUs of the time the MMU that brought paging to the party often was a completely separate peripheral that the CPU interacted with to gate access to RAM. By contrast segments are an integral part of the CPU instruction set and your code either has to limit itself to 64KB or your application had to be aware of and include logic to manage segments. As an aside, the memory model is flat, it's just not physically linear when implementing virtual memory addressing.

phkahler 4mo ago

I was drooling over the MC68000. I had a pre-release reference manual from 1979 and it was the most awesome chip around. Atari and Commodore and Apple used it after their 6502 systems. Arcade games used it after their 6502 and 6809 days. The only reason x86 became popular was because IBM put it in the PC - not for any technical reasons.

trollbridge 4mo ago
A 68k was roughly double the cost of an 8086, plus the additional cost for the rest of the supporting chips. The PC was intended to be cheap and was competing with 8 bit machines. Being 16/20 bit made it already high end. If you wanted 24 or 32 bit, IBM had many other machines to sell you. Or you could just buy a VAX.

ThrowawayR2 4mo ago

Flat memory was a better idea but it wasn't a cheaper idea, and cheaper beats good. A casual Googling shows a price of $2,880 for a IBM PC in ~1982 dollars versus $8,900 for a Sun Microsystems Sun-1 with a MC68000.

amiga386 4mo ago
That was just Sun's market segment. Also from a casual Google, an IBM PC launched in 1985 (picking the XT 5160-078 as an example) was around $4,995 at launch. Compare that to two 68000-based computers also launched in 1985: the Amiga 1000 launched at $1,295 and the Atari 520ST launched at $600. These computer system prices - Sun, IBM, Commodore, Atari - came from the market segments the manufacturers aimed to sell to, rather than a cost saving enabled by cumbersome memory models. The cumbersome memory model is just a historical accident; the 8086 designers wanted 8080 backwards compatibility so they could sell to former 8080 users, IBM did not require this. IBM would've picked the 68000 had it been "production ready" at the time, they did not reject flat memory on cost grounds!
- dfe 4mo ago
  Are you sure IBM didn't care about 8080 compatibility? The PC was released in August 1981, a full 4 years before any of the other machines you speak of. That XT 5160-078 you speak of is a cost-reduced model with no hard drive from IBM, allowing dealers to install a compatible hard drive from a different supplier. By 1985, the PC AT (286) had already been out since August 1984. And the original XT was October of 1983. And the XT itself is literally the same as a PC with more expandability: 8 slots instead of 5, beefier PSU, room for a hard drive. It's unclear if IBM or for that matter anyone would have been able to start designing a 68000-based machine and bring it to market by the fall of 1981. Sun brought the Sun 1 to market in May 1982, so about 9 months later, and with a much higher price. And what did the Sun run? UNIX. What did IBM run? Quick ports of the last several years of CP/M software made possible because DOS 1 was specifically designed to implement a CP/M-like API, and the 8086 was specifically designed to allow porting of 8080 assembler code directly to small model 8086 code.

trollbridge 4mo ago

Flat is not necessarily a better idea. In 1978, a 32 bit CPU would be stupidly expensive. The use case for > 64k was to simply have code and data split apart, and also have some MMIO, so basically 192k-256k of addressing needed. Segmentation meant programs could remain essentially 16 bit with all the benefits to that like smaller code size.