6 ms·

The 8086 and 80286 were so difficult to program, both in assembler and higher level languages. Everyone was relieved when the 386 and 486 came around - at last

The 8086 and 80286 were so difficult to program, both in assembler and higher level languages. Everyone was relieved when the 386 and 486 came around - at last you could program sensibly and use operating systems that didn't crash all the time because of good memory protection.

chihuahua 2y ago
I was doing a lot of 6502 and 68000 assembly programming. Then (around 1988?) I got a PC with an 80286, and bought a book that described the 80286 instruction set. After reading it, I said "this is some bullshit" and returned the book for a refund. I had zero interest in writing a single line of code for that processor.
- dougvj 2y ago
  I first learned assembly on the x86 and wasn't until years later that I picked up m68k asm for a hobby computer and all that time I just assumed assembly was either gnarly and difficult like x86 or very bare bones for compilers (like the RISC isas). I didn't realize there was a such thing as nice, programmer oriented assembly.
- Pet_Ant 2y ago
  Can you tell us what the vast difference was that made you give up programming for it? I've only assembled SPARC in college, so I have no basis of comparison.
  - chihuahua 2y ago
    It was a long time ago (37 years?) but the main difference is this: The Motorola 68000 has 8 32-bit data registers and 8 32-bit address registers. They are named D0..D7 and A0..A7. You can use these in most instructions in the obvious/expected way. Maybe it's not completely orthogonal, but close enough. With those registers, you can keep 8 intermediate values and 8 pointers, and perform reasonable operations on them (add this and that, and store at that address) The 80286 instruction has just 4 16-bit registers, 4 more registers with strange names (BP, SI, DI, SP) and 4 segment registers. None of these are general-purpose. I just looked it up and apparently, you can only use AX and DX for multiply/divide instructions. The segmented addressing is what is most repulsive about the whole thing: you can't just put an address into a register. You have to use a segment register and use an offset so the real address is (segment register value)*16 + offset. The reason for all this bad design is presumably compatibility with even more primitive earlier processors (8086, 8088, 8085, 8080). All this backward compatibility is so painful and limiting. The 68k was launched in 1979 and it gets all of this right (32-bit addresses, general purpose registers), but the 8086 was launched in 1978 and it's so primitive and ugly. It reminds me of Windows which even today has certain dumb features such as "\" being the path separator for compatibility with CP/M, some primitive relic of the 1970s. I understand the importance of backward compatibility for commercial success, but it's so ugly and I just don't want to have to deal with it decades later. Yes I know that the NT kernel can theoretically use a different path separator, but in practice, we're all still using \ for paths and / for command line options. Because CP/M was so incredibly great in 1975.
ghssds 2y ago
When an OS making use of 386's features became mainstream we were well into the '90s. By that time the 386 itself was long obsolete. If by everyone you mean almost nobody, then I agree because that's how many people used the 386 as a 386 and not simply a fast 8086.
- twoodfin 2y ago
  Windows 3.0/3.1 offered a 386 Enhanced mode with significant benefits: https://en.wikipedia.org/wiki/Windows_3.0 https://en.wikipedia.org/wiki/Windows_3.0 Windows 3.0 arrived in 1990.
  - icedchai 2y ago
    DESQview 386, a DOS multitasker, was released a little bit earlier. Probably more useful than Windows at the time given the popularity of DOS applications. I remember some local BBSes running multiple "nodes" in DESQview.
    - lynx97 2y ago
      [dead]
  - skissane 2y ago
    > Windows 3.0/3.1 offered a 386 Enhanced mode with significant benefits: Which was a follow-up to Windows/386 2.0 released in 1987. I guess the big difference is few people ever used Windows 2.x, even in its 8086 variant, and use of its 386 variant was even rarer. Whereas Windows 3.0 was widely adopted. And by the time Windows 3.0 came out, 386 machines had become much more common too
    - adrian_b 2y ago
      Previous Windows versions were for 8088 or 80286, which caused serious limitations for how memory was allocated and used (e.g. the programs had to be written in such a way as to allow the operating system to change the values of the pointers, whenever it needed to move the already allocated memory regions to other places). While Windows 3.0 had compatibility modes with earlier Windows versions, its native mode was designed for 80386, which allowed a completely different programming model, removing the annoying limitations of the older Windows versions. Saying that Windows 3.0 was a follow-up is not really appropriate because it was a very different operating system, even if many APIs had remained as compatible as possible with the earlier Windows versions.
fargle 2y ago
> The 8086 and 80286 were so difficult to program, both in assembler and higher level languages. 286 protected modes, sure. 16-bit 8086, no way. difficulty of use did not hinder. celebrating proper 32-bit protected modes, absolutely agree. but x86 was still well liked and used and was not the clunker that 286 was.
- npsomaratna 2y ago
  Anyone here remember the LOADALL instruction? Fun times.
  - guiambros 2y ago
    Ralph Brown enters the chat...
timewizard 2y ago
Banked or segmented memory was a common CPU feature of the time. It's look back upon with a disdain that simply didn't exist at the time.
- qingcharles 2y ago
  I agree. I don't particularly remember any disdain at the time. It was just a thing that you worked with. Sure, it made things more complicated. Sure, it was easier with a flat address space. But there were way bigger problems in day-to-day development than segmented memory.
- drmpeg 2y ago
  On 8086, the assembler managed the segmentation. All you had to do was load the DS (and possibly ES) register with an assembler defined symbol at the beginning of your function. I never worked with the 80286, I pivoted to the i960 around 1992.
- pjc50 2y ago
  Segmented memory isn't that weird. What was weird was that, instead of the obvious way of concatenating two sixteen-bit registers to produce a 32-bit address, they added them together to produce a 20-bit address. In addition to which there was some hardware nonsense with the top address bit ("gate A20"). This system seemed practically designed to generate pointer aliasing, and it also permanently limited the architecture to one megabyte of addressable memory. Whereas the concatenation system could have been extended by simply exposing more bits of the address bus on CPU pins. The shenanigans to get DOS machines to use more than 640k (which the application had to share with the OS and drivers!) are stuck in my memory.
  - kjs3 2y ago
    Gate A20 and 640k memory limits are because of the design of the IBM PC and M$ DOS, not the 8086. Better hardware and software didn't have these limits (they had others).
  - timewizard 2y ago
    > This system seemed practically designed to generate pointer aliasing, We did not care about that then. Primarily because SMP and threads were simply not a thing. You might also note that any implementation of mmap(2) provides the exact same facility. > permanently limited the architecture to one megabyte of addressable memory It limited the generation. The architecture has obviously moved well past that. Now you can complain that though you have 64 bits only 48 are routed out to pins on your board. > The shenanigans to get DOS machines to use more than 640k (which the application had to share with the OS and drivers!) are stuck in my memory. hah. Program on a mainframe in 24bit mode sometime. That's a real treat.
pjmlp 2y ago
I disagree, it felt perfectly natural to me, coming up from 8 bit, and having done my little stay on the demoscene back in the day.

chihuahua 2y ago

I was doing a lot of 6502 and 68000 assembly programming. Then (around 1988?) I got a PC with an 80286, and bought a book that described the 80286 instruction set. After reading it, I said "this is some bullshit" and returned the book for a refund. I had zero interest in writing a single line of code for that processor.

dougvj 2y ago
I first learned assembly on the x86 and wasn't until years later that I picked up m68k asm for a hobby computer and all that time I just assumed assembly was either gnarly and difficult like x86 or very bare bones for compilers (like the RISC isas). I didn't realize there was a such thing as nice, programmer oriented assembly.
Pet_Ant 2y ago
Can you tell us what the vast difference was that made you give up programming for it? I've only assembled SPARC in college, so I have no basis of comparison.
- chihuahua 2y ago
  It was a long time ago (37 years?) but the main difference is this: The Motorola 68000 has 8 32-bit data registers and 8 32-bit address registers. They are named D0..D7 and A0..A7. You can use these in most instructions in the obvious/expected way. Maybe it's not completely orthogonal, but close enough. With those registers, you can keep 8 intermediate values and 8 pointers, and perform reasonable operations on them (add this and that, and store at that address) The 80286 instruction has just 4 16-bit registers, 4 more registers with strange names (BP, SI, DI, SP) and 4 segment registers. None of these are general-purpose. I just looked it up and apparently, you can only use AX and DX for multiply/divide instructions. The segmented addressing is what is most repulsive about the whole thing: you can't just put an address into a register. You have to use a segment register and use an offset so the real address is (segment register value)*16 + offset. The reason for all this bad design is presumably compatibility with even more primitive earlier processors (8086, 8088, 8085, 8080). All this backward compatibility is so painful and limiting. The 68k was launched in 1979 and it gets all of this right (32-bit addresses, general purpose registers), but the 8086 was launched in 1978 and it's so primitive and ugly. It reminds me of Windows which even today has certain dumb features such as "\" being the path separator for compatibility with CP/M, some primitive relic of the 1970s. I understand the importance of backward compatibility for commercial success, but it's so ugly and I just don't want to have to deal with it decades later. Yes I know that the NT kernel can theoretically use a different path separator, but in practice, we're all still using \ for paths and / for command line options. Because CP/M was so incredibly great in 1975.

ghssds 2y ago

When an OS making use of 386's features became mainstream we were well into the '90s. By that time the 386 itself was long obsolete. If by everyone you mean almost nobody, then I agree because that's how many people used the 386 as a 386 and not simply a fast 8086.

twoodfin 2y ago
Windows 3.0/3.1 offered a 386 Enhanced mode with significant benefits: https://en.wikipedia.org/wiki/Windows_3.0 https://en.wikipedia.org/wiki/Windows_3.0 Windows 3.0 arrived in 1990.
- icedchai 2y ago
  DESQview 386, a DOS multitasker, was released a little bit earlier. Probably more useful than Windows at the time given the popularity of DOS applications. I remember some local BBSes running multiple "nodes" in DESQview.
  - lynx97 2y ago
    [dead]
- skissane 2y ago
  > Windows 3.0/3.1 offered a 386 Enhanced mode with significant benefits: Which was a follow-up to Windows/386 2.0 released in 1987. I guess the big difference is few people ever used Windows 2.x, even in its 8086 variant, and use of its 386 variant was even rarer. Whereas Windows 3.0 was widely adopted. And by the time Windows 3.0 came out, 386 machines had become much more common too
  - adrian_b 2y ago
    Previous Windows versions were for 8088 or 80286, which caused serious limitations for how memory was allocated and used (e.g. the programs had to be written in such a way as to allow the operating system to change the values of the pointers, whenever it needed to move the already allocated memory regions to other places). While Windows 3.0 had compatibility modes with earlier Windows versions, its native mode was designed for 80386, which allowed a completely different programming model, removing the annoying limitations of the older Windows versions. Saying that Windows 3.0 was a follow-up is not really appropriate because it was a very different operating system, even if many APIs had remained as compatible as possible with the earlier Windows versions.

fargle 2y ago

> The 8086 and 80286 were so difficult to program, both in assembler and higher level languages. 286 protected modes, sure. 16-bit 8086, no way. difficulty of use did not hinder. celebrating proper 32-bit protected modes, absolutely agree. but x86 was still well liked and used and was not the clunker that 286 was.

npsomaratna 2y ago
Anyone here remember the LOADALL instruction? Fun times.
- guiambros 2y ago
  Ralph Brown enters the chat...

timewizard 2y ago

Banked or segmented memory was a common CPU feature of the time. It's look back upon with a disdain that simply didn't exist at the time.

qingcharles 2y ago
I agree. I don't particularly remember any disdain at the time. It was just a thing that you worked with. Sure, it made things more complicated. Sure, it was easier with a flat address space. But there were way bigger problems in day-to-day development than segmented memory.
drmpeg 2y ago
On 8086, the assembler managed the segmentation. All you had to do was load the DS (and possibly ES) register with an assembler defined symbol at the beginning of your function. I never worked with the 80286, I pivoted to the i960 around 1992.
pjc50 2y ago
Segmented memory isn't that weird. What was weird was that, instead of the obvious way of concatenating two sixteen-bit registers to produce a 32-bit address, they added them together to produce a 20-bit address. In addition to which there was some hardware nonsense with the top address bit ("gate A20"). This system seemed practically designed to generate pointer aliasing, and it also permanently limited the architecture to one megabyte of addressable memory. Whereas the concatenation system could have been extended by simply exposing more bits of the address bus on CPU pins. The shenanigans to get DOS machines to use more than 640k (which the application had to share with the OS and drivers!) are stuck in my memory.
- kjs3 2y ago
  Gate A20 and 640k memory limits are because of the design of the IBM PC and M$ DOS, not the 8086. Better hardware and software didn't have these limits (they had others).
- timewizard 2y ago
  > This system seemed practically designed to generate pointer aliasing, We did not care about that then. Primarily because SMP and threads were simply not a thing. You might also note that any implementation of mmap(2) provides the exact same facility. > permanently limited the architecture to one megabyte of addressable memory It limited the generation. The architecture has obviously moved well past that. Now you can complain that though you have 64 bits only 48 are routed out to pins on your board. > The shenanigans to get DOS machines to use more than 640k (which the application had to share with the OS and drivers!) are stuck in my memory. hah. Program on a mainframe in 24bit mode sometime. That's a real treat.

pjmlp 2y ago

I disagree, it felt perfectly natural to me, coming up from 8 bit, and having done my little stay on the demoscene back in the day.