18 ms·

Author here for all your 8086 questions :-)

by kens 4y ago

pwg 4y ago
Ken, one tiny update. You have "a 4-megabyte (20-bit) address space" near the top of your post. 2^20 is a 1 Megabyte (in base-2 'megabytes') not a 4 megabytes address space.
- kens 4y ago
  I got it fixed just before your comment :-)
benlivengood 4y ago
Do you still write 8086 assembly for fun? I grew up with DOS, a86, and nasm and remember those times fondly. Once I had flat mode in Linux I never really looked back, and once I had x86_64 I never looked back, and now I rarely even delve below the interpreted/compiled level unfortunately. x86 had a closeness to the hardware that was fun to play with.
- kens 4y ago
  Strangely enough, I haven't written 8086 assembly since 1988, when I wrote the ellipse-drawing code used in Windows.
  - garganzol 4y ago
    Pardon my interest, are you happen to be a former Microsoftee?
    - kens 4y ago
      I was an intern in the summer of 1988. Instead of staying, I went back to grad school which in retrospect probably cost me a fortune :-)
  - madmoose 4y ago
    Aaron Giles was just lamenting the other day that the GDI ellipse drawing is apparently slightly lopsided, since he's trying to recreate it :) https://corteximplant.com/@aaronsgiles/110121906721852861 https://corteximplant.com/@aaronsgiles/110121906721852861
    - kens 4y ago
      Hopefully that's not my bug :-) Before my code [1], small ellipses looked terrible: a small circle looked like a stop sign and others looked corrugated. [1] I can't take much credit. The code was Bresenham's algorithm, as explained to me by the OS/2 group. At the time, OS/2 was the cool operating system that was the wave of the future and Windows was this obscure operating system that nobody cared about. The impression I got was that the OS/2 people didn't really want to waste their time talking to us.
myself248 4y ago
It's always boggled my mind that they'd have 32 bits of addressing registers, but overlap 12 bits, leaving just 20 useful bits. What a waste. I guess the segment:offset scheme had some advantages, but honestly, I've never felt like I had a good understanding of them. But, what if the overlap had been just 10 bits, or just 8, leaving a much larger functional address range before we got clobbered by the 20-bit limit; what if it was 22 or 24 bits of useful range? Can you speculate what effect such a decision would've had, and why it wasn't taken at the time? I understand in 1978 even 20 bits was a lot, but was that optimal?
- pwg 4y ago
  The 20 bits of address was likely a direct result of Intel's decision to package the 8086 in a 40-pin package. They already multiplex the 16-bit data bus on top of 16 of the 20 pins of the address bus. But with only 40 pins, that 20-bit address bus was already using half of the total chip pinout. And, at the time the 8086 was being designed (circa. 1976-1978) with other microprocessors of the time having 16-bit or smaller address buses, the jump to 1M of possible total address space was likely seen as huge. We look back now, comfortable with 12+GB of RAM as a common size, and see 1M as small. But when your common size is 16-64k, having 1M as a possibility would likely seem huge.
  - dfox 4y ago
    It was not that much of an engineering decision as a simple requirement for the chip to be feasible. At that time 40pin DIL was effectively the largest package that could be made at production scale.
    - kens 4y ago
      Intel's decision to use a 40-pin chip was mainly because Intel had a weird drive for small integrated circuits. The Texas Instruments TMS9900 (1976) used a 64-pin package for instance, as did the Motorola 68000 (1979). For the longest time, Intel was fixated on 16-pin chips, which is why the Intel 4004 processor was crammed into a 16-pin package. The 8008 designers were lucky that they were allowed 18 pins. The Oral History of Federico Faggin [1] describes how 16-pin packages were a completely silly requirement, but the "God-given 16 pins" was like a religion at Intel. He hated this requirement because it was throwing away performance. When Intel was forced to 18 pins by the 1103 memory chip, it "was like the sky had dropped from heaven" and he had "never seen so many long faces at Intel." [1] pages 55-56 of http://archive.computerhistory.org/resources/text/Oral_History/Faggin_Federico/Faggin_Federico_1_2_3.oral_history.2004.102658025.pdf http://archive.computerhistory.org/resources/text/Oral_Histo...
mysterydip 4y ago
Is there a performance advantage to using a microcoded instruction vice explicitly calling each instruction? Or is it a space/bugs-while-coding savings?
- rep_lodsb 4y ago
  A non-repeated string opcode is one byte for the CPU to fetch vs. several for the corresponding "RISC-like" series of operations (load, increment SI, store/compare, increment DI). With the REP prefix (another single byte), an entire loop could run in microcode without any additional instruction fetches. Remember that each memory access took 4 clock cycles and there was no cache yet. -- Eliminating opcode fetches might still speed things up today in some situations, but modern x86 cores are optimized to decode and dispatch several simple operations each cycle without having to go through a microcode ROM (and thus have to use a slower path for the complex instructions). Also the fact that compilers didn't emit most of the more complex/specialized instructions led to Intel not spending much effort on optimizing those.
  - userbinator 4y ago
    Also the fact that compilers didn't emit most of the more complex/specialized instructions led to Intel not spending much effort on optimizing those. I believe some compilers will still emit rep movs for memcpy, rep stos for memset, rep cmps for memcmp, and sometimes even rep scas for memchr/strlen if given the appropriate options.
- bell-cot 4y ago
  Directly implementing many & complex instructions in silicon is fast, but takes a lot of transistors. Microcode running on a much simpler "actual" processor is slower, but requires far fewer transistors. IIR, ~all substantial CPU's of the past ~40 years have mixed the two approaches. (Microcode also makes it possible to design in bug-patching features. Possibly including patches for bugs in your direct-implemented instructions.)
bonzini 4y ago
In the SCAS/CMPS annotated microcode, the path with the R DS microinstruction is for CMPS, not SCAS. SCAS compares AX against [ES:DI] while CMPS compares [DS:SI] against [ES:DI], so the paragraph before is slightly incorrect (should be "SCAS compares against the character in the accumulator, while CMPS reads the comparison character from SI").
- kens 4y ago
  Thanks, I've fixed the post.

Author here for all your 8086 questions :-)

by kens 4y ago

Author here for all your 8086 questions :-)

pwg 4y ago

Ken, one tiny update. You have "a 4-megabyte (20-bit) address space" near the top of your post. 2^20 is a 1 Megabyte (in base-2 'megabytes') not a 4 megabytes address space.

kens 4y ago
I got it fixed just before your comment :-)

benlivengood 4y ago

Do you still write 8086 assembly for fun? I grew up with DOS, a86, and nasm and remember those times fondly. Once I had flat mode in Linux I never really looked back, and once I had x86_64 I never looked back, and now I rarely even delve below the interpreted/compiled level unfortunately. x86 had a closeness to the hardware that was fun to play with.

kens 4y ago
Strangely enough, I haven't written 8086 assembly since 1988, when I wrote the ellipse-drawing code used in Windows.
- garganzol 4y ago
  Pardon my interest, are you happen to be a former Microsoftee?
  - kens 4y ago
    I was an intern in the summer of 1988. Instead of staying, I went back to grad school which in retrospect probably cost me a fortune :-)
- madmoose 4y ago
  Aaron Giles was just lamenting the other day that the GDI ellipse drawing is apparently slightly lopsided, since he's trying to recreate it :) https://corteximplant.com/@aaronsgiles/110121906721852861 https://corteximplant.com/@aaronsgiles/110121906721852861
  - kens 4y ago
    Hopefully that's not my bug :-) Before my code [1], small ellipses looked terrible: a small circle looked like a stop sign and others looked corrugated. [1] I can't take much credit. The code was Bresenham's algorithm, as explained to me by the OS/2 group. At the time, OS/2 was the cool operating system that was the wave of the future and Windows was this obscure operating system that nobody cared about. The impression I got was that the OS/2 people didn't really want to waste their time talking to us.

myself248 4y ago

It's always boggled my mind that they'd have 32 bits of addressing registers, but overlap 12 bits, leaving just 20 useful bits. What a waste. I guess the segment:offset scheme had some advantages, but honestly, I've never felt like I had a good understanding of them. But, what if the overlap had been just 10 bits, or just 8, leaving a much larger functional address range before we got clobbered by the 20-bit limit; what if it was 22 or 24 bits of useful range? Can you speculate what effect such a decision would've had, and why it wasn't taken at the time? I understand in 1978 even 20 bits was a lot, but was that optimal?

pwg 4y ago
The 20 bits of address was likely a direct result of Intel's decision to package the 8086 in a 40-pin package. They already multiplex the 16-bit data bus on top of 16 of the 20 pins of the address bus. But with only 40 pins, that 20-bit address bus was already using half of the total chip pinout. And, at the time the 8086 was being designed (circa. 1976-1978) with other microprocessors of the time having 16-bit or smaller address buses, the jump to 1M of possible total address space was likely seen as huge. We look back now, comfortable with 12+GB of RAM as a common size, and see 1M as small. But when your common size is 16-64k, having 1M as a possibility would likely seem huge.
- dfox 4y ago
  It was not that much of an engineering decision as a simple requirement for the chip to be feasible. At that time 40pin DIL was effectively the largest package that could be made at production scale.
  - kens 4y ago
    Intel's decision to use a 40-pin chip was mainly because Intel had a weird drive for small integrated circuits. The Texas Instruments TMS9900 (1976) used a 64-pin package for instance, as did the Motorola 68000 (1979). For the longest time, Intel was fixated on 16-pin chips, which is why the Intel 4004 processor was crammed into a 16-pin package. The 8008 designers were lucky that they were allowed 18 pins. The Oral History of Federico Faggin [1] describes how 16-pin packages were a completely silly requirement, but the "God-given 16 pins" was like a religion at Intel. He hated this requirement because it was throwing away performance. When Intel was forced to 18 pins by the 1103 memory chip, it "was like the sky had dropped from heaven" and he had "never seen so many long faces at Intel." [1] pages 55-56 of http://archive.computerhistory.org/resources/text/Oral_History/Faggin_Federico/Faggin_Federico_1_2_3.oral_history.2004.102658025.pdf http://archive.computerhistory.org/resources/text/Oral_Histo...

mysterydip 4y ago

Is there a performance advantage to using a microcoded instruction vice explicitly calling each instruction? Or is it a space/bugs-while-coding savings?

rep_lodsb 4y ago
A non-repeated string opcode is one byte for the CPU to fetch vs. several for the corresponding "RISC-like" series of operations (load, increment SI, store/compare, increment DI). With the REP prefix (another single byte), an entire loop could run in microcode without any additional instruction fetches. Remember that each memory access took 4 clock cycles and there was no cache yet. -- Eliminating opcode fetches might still speed things up today in some situations, but modern x86 cores are optimized to decode and dispatch several simple operations each cycle without having to go through a microcode ROM (and thus have to use a slower path for the complex instructions). Also the fact that compilers didn't emit most of the more complex/specialized instructions led to Intel not spending much effort on optimizing those.
- userbinator 4y ago
  Also the fact that compilers didn't emit most of the more complex/specialized instructions led to Intel not spending much effort on optimizing those. I believe some compilers will still emit rep movs for memcpy, rep stos for memset, rep cmps for memcmp, and sometimes even rep scas for memchr/strlen if given the appropriate options.
bell-cot 4y ago
Directly implementing many & complex instructions in silicon is fast, but takes a lot of transistors. Microcode running on a much simpler "actual" processor is slower, but requires far fewer transistors. IIR, ~all substantial CPU's of the past ~40 years have mixed the two approaches. (Microcode also makes it possible to design in bug-patching features. Possibly including patches for bugs in your direct-implemented instructions.)

bonzini 4y ago

In the SCAS/CMPS annotated microcode, the path with the R DS microinstruction is for CMPS, not SCAS. SCAS compares AX against [ES:DI] while CMPS compares [DS:SI] against [ES:DI], so the paragraph before is slightly incorrect (should be "SCAS compares against the character in the accumulator, while CMPS reads the comparison character from SI").

kens 4y ago
Thanks, I've fixed the post.