9 ms·

Yes, the 8086 wanted to be mechanically translatable from the 8080, but

219 points by zdw 4y ago

pdimitar 4y ago
Slight off-topic and tangent: I am looking into writing some basic compiler(s) but I really want to emphasize micro-optimizations, maybe even the stochastic ones -- don't ask why, it's just an obsession. Question: is there an Arduino-like hardware that allows FULL visibility into the efficiency of every piece of code ran on it? On my first job, 20 years ago, there was a team working on embedded boards that maybe did something similar. But again, I am looking for a piece of hardware -- and a software stack for it -- where you say "here's this chunk of assembly / machine code, run it and give me detailed statistics which instruction got ran the most times, which one took the longest time" etc.? Is there something like that out there?
f311a 4y ago
After reading the title and domain name, I already knew who the author is.
- rjbwork 4y ago
  Lol. My exact thoughts before clicking the link "Let me guess, this is Chen"
  - AceJohnny2 4y ago
    Everybody Loves Raymond
- commonlisper 4y ago
  Exactly! Raymond Chen is doing a great job at sharing interesting stories from a bygone era.
  - criddell 4y ago
    Bygone? It's a fairly regular occurrence where I search for some Win32 API and end up on Chen's blog. I get what you are saying about articles like this one though. I can't imagine much new work is happening with the 8086 (or 8088 or '186 or '286 or ...)
    - GabrielTFS 4y ago
      I mean even w.r.t. Windows stuff, quite a large part of what he talks about is variations on "here's an interesting old anecdote from 1995" or "You know that thing that's totally useless now and doesn't matter ? Here's why we absolutely needed it in 1989."
hacknat 4y ago
My favorite Chen article: Why do Windows functions all begin with a pointless MOV EDI, EDI instruction? https://devblogs.microsoft.com/oldnewthing/20110921-00/?p=9583 https://devblogs.microsoft.com/oldnewthing/20110921-00/?p=95...
- omnibrain 4y ago
  It's such a shame that they killed (twice now?) all the comments in the blog.
  - game-of-throws 4y ago
    They also changed the URL at least once and broke all links to it. His posts deserve better.
  - password4321 4y ago
    Yes, I miss my weekly-ish from Raymond's arch nemesis Yuhong Bao. For this specific blog post there's an HN discussion¹ and archive.today² (beware!?³) did grab comments while the Internet Archive does not load them: ¹ https://news.ycombinator.com/item?id=3022224 https://news.ycombinator.com/item?id=3022224 ² http://archive.today/2015.07.08-134638/http://blogs.msdn.com/b/oldnewthing/archive/2011/09/21/10214405.aspx http://archive.today/2015.07.08-134638/http://blogs.msdn.com... ³ https://news.ycombinator.com/item?id=31945924#31946453 https://news.ycombinator.com/item?id=31945924#31946453
    - m463 4y ago
      nice use of superscripts
  - mananaysiempre 4y ago
    There is a more-or-less comprehensive archive[1] up to 2019 (which should probably be scraped and hoarded). The article in question is there, comments included[2]. Side note: Michael Kaplan’s blog, which Microsoft took down in a remarkably shameful manner, has also been archived[3], while Eric Lippert reposted (most of?) his old articles on his personal WordPress instance[4]. [1] http://bytepointer.com/resources/old_new_thing/index.htm http://bytepointer.com/resources/old_new_thing/index.htm [2] http://bytepointer.com/resources/old_new_thing/20110921_226_why_do_windows_functions_all_begin_with_a_pointless_mov_edi_edi_instruction.htm http://bytepointer.com/resources/old_new_thing/20110921_226_... [3] http://archives.miloush.net/michkap/archive/ http://archives.miloush.net/michkap/archive/ [4] https://ericlippert.com/ https://ericlippert.com/
kazinator 4y ago
> "there was no room" They were saving it for 286, 386, ... MMX, AVX, SSE, ...
- olliej 4y ago
  x86 is variable length, and so extensions were able to use prefix bytes to distinguish them. On the plus side that means common instructions are still actually compact so reducing icache pressure.
  - rep_lodsb 4y ago
    It's not so compact anymore! Using 64-bit registers, or any of R8-R15, requires a prefix byte. The single-byte INC/DEC opcodes have been repurposed for this. And for performance reasons having to do with how it affects the flags, you don't want to use INC/DEC (now two bytes) at all. So now the very common operation of incrementing a register takes at least three bytes, four if it needs the prefix. Legacy instructions have been made invalid - depending more on the whims of Intel/AMD than whether they are actually useful - but still clutter up the opcode space.
    - olliej 4y ago
      Obviously it has expanded, and not saying "let's completely replace the ISA in 64bit modes" means that a bunch of cruft is going to be consuming the ISA space. At the same time there is a lot of code that isn't using 64bit values so the compact coding can still be used. But while talking about ISA size and compactness, we need to compare to the real world alternative: the various ARM or RISC-V ISAs, etc are all 4byte per instruction with the occasional 2 byte variable length extensions*. 4 byte does seem to have been what has been selected for. My experience with code size is wrapped up in jitting JS so I could believe my experience isn't as reflective of real world code size as it could be :D * fun story: thumb2 had an early bug/errata where a 4 byte branch spanning a page boundary would jump to the wrong page.
aftbit 4y ago
>These redundant encodings are used by some assemblers to “fingerprint” their output. Fascinating! Does anyone have links to more information about this? What purpose might one have for this fingerprinting?
- retrac 4y ago
  If you sell a commercial compiler or assembler, and some company starts selling a product produced with your compiler/assembler, and you know you never sold them a license, you've got yourself someone to sue. For a less successful/commercial product, it could also just be for the joy of finding it used in the wild. Similar fingerprinting techniques were also used by assembly coders as proof of copyright. When reverse-engineering to a spec, it's not unusual for routines, even long routines, as well as lookup tables, etc. to end up being coded the same, or nearly so, as the original software. This isn't necessarily infringing of copyright -- for example there are only a few sensible ways to check if a character is uppercase in ASCII. It can be hard to tell reverse-engineered and re-implemented code, from disassembled and reshuffled code (which is copyright infringement). If the suspect routine incorporates something like an idiosyncratic sequence of NOPs that serve no particular purpose, coincidence is a lot harder to argue.
- bell-cot 4y ago
  One example (scroll down to 'Code fingerprint') - https://en.wikipedia.org/wiki/A86_(software) https://en.wikipedia.org/wiki/A86_(software)
  - rep_lodsb 4y ago
    Can anyone find a version of A86 that actually encodes some information in its output, or is this just a legend? It produces different opcodes for some instructions than MASM, but so do DEBUG and various other assemblers. And the same instruction repeated multiple times always assembles to the same opcode as far as I have seen. To prove some program was made with A86, there would have to be a more specific signature that wouldn't match any other assembler, like a copyright message encoded bit-by-bit in the opcode choice.
Linda703 4y ago
[dead]
rep_lodsb 4y ago
IMO the base+index encoding (in 16-bit x86) was a mistake, it should have simply allowed indirection through any single register (+ immediate offset), including SP. • the address calculation would be simple enough to do hardwired even on the original 8086, instead of using slow microcode. The 8086 actually took a different amount of clock cycles depending on the registers used for base and index, because there wasn't enough ROM space to duplicate the code for every combination without using jumps! • you could use [SP+xxxx] to access local variables (frame pointer omission) • would be able to emulate the 8080's LDAX/STAX and XTHL in a single instruction • with so few registers, you really want every one available for memory addressing. Especially AX which is used implicitly by instructions like LODSW and MUL.
- AceJohnny2 4y ago
  That would require additional transistors/surface, which was at a premium. The 8086 was designed under harsh technical constraints by moderns standards. Don't forget that.
  - AceJohnny2 4y ago
    TBH I'm still flabbergasted that modern SoCs will "just put a CPU there" rather than a DMA, because we can actually afford it. 6502 cores are sprinkled around like fairy dust.
    - jffry 4y ago
      The FPGA dev boards I worked with in a college course circa 2009 had a couple of PowerPC cores thrown in as a bonus, with a whole system for being able to interface between CPU and FPGA: https://www.xilinx.com/content/dam/xilinx/support/documents/ip_documentation/ppc440_virtex5.pdf https://www.xilinx.com/content/dam/xilinx/support/documents/...
      - deelowe 4y ago
        It's still common today. The de-10 nano of mister fame leverages the hard processor to great affect.
VogonPoetry 4y ago
Given that the 8086 has SI and DI with a +imm8 mode, like the (IX+imm8) and (IY+imm8) instructions on the Z80. I do wonder if Z80 CP/M machines were the real target rather than the 8080. I did write an 8086 assembly based Z80 emulator (in the late 80's) that was surprisingly compact and had acceptable Z80 performance on a 12MhZ AMD 80286. It passed CP/M system calls to Concurrent DOS. I should see if I still have the code and run an emulator torture test to see how bad it was.
- rep_lodsb 4y ago
  Too bad that you need SI for the program counter, and DI to emulate some addressing modes that the 8080 could do but x86 can't. Even if translating code ahead of time, "LD (BC), A" needs to be emulated as something like "MOV DI,CX; MOV [DI],AL".
  - VogonPoetry 4y ago
    I went and found my code, with a side trip into being able to "unzoo" the archive! Yes, I agree. I also used SI as the PC so I could use "lodsb" (cute HN name BTW) and "lodsw" for 2 byte args. My register use was 286 Z80 --- --- BX HL CX BC DX DE DI A SI PC When emulating the DD, FD and CB prefixes I pre-loaded BP with either IX+d, IY+d (IX, IY were stored in memory) or BX and jumping to common code. Basic structure was like OP_00: XOR AH,AH LODSB SHL AX,1 MOV BP,AX JMP CS:OP_table[BP] For OP_02 - "LD (BC),A" I used, OP_02: XCHG CX,DI MOV [DI], CL XCHG CX,DI JMP OP_00 I did see some opportunities for additional code-golf. Also noticed that EX AF,AF' did not properly exchange the flags (so that will need to get fixed!). I was mostly only running m80, l80 and mload.
quickthrower2 4y ago
Suggestion: Remove the “Yes, “ and “, but” from the title to make it more HN-ish.
- rep_lodsb 4y ago
  Memory safety should have been more a concern for the design of the 8086! And if 8080 backwards compatibility is really necessary, we can write an emulator in Rust, compiled to WebAssembly and running on RISC-V. /s
JadeNB 4y ago
I thought the trailing-off title was some sort of clickbait (which would be weird for Chen!); but actually the title is "Yes, the 8086 wanted to be mechanically translatable from the 8080, but why not add the ability to indirect through AX, CX and DX?", and I guess it just got asemantically chopped on HN's end. (To avoid my own clickbait, the one-sentence answer from the article, on which of course the rest of the article elaborates, is "Basically, because there was no room.")
sharmin123 4y ago

219 points by zdw 4y ago

Slight off-topic and tangent: I am looking into writing some basic compiler(s) but I really want to emphasize micro-optimizations, maybe even the stochastic ones -- don't ask why, it's just an obsession. Question: is there an Arduino-like hardware that allows FULL visibility into the efficiency of every piece of code ran on it? On my first job, 20 years ago, there was a team working on embedded boards that maybe did something similar. But again, I am looking for a piece of hardware -- and a software stack for it -- where you say "here's this chunk of assembly / machine code, run it and give me detailed statistics which instruction got ran the most times, which one took the longest time" etc.? Is there something like that out there?

f311a 4y ago

After reading the title and domain name, I already knew who the author is.

rjbwork 4y ago
Lol. My exact thoughts before clicking the link "Let me guess, this is Chen"
- AceJohnny2 4y ago
  Everybody Loves Raymond
commonlisper 4y ago
Exactly! Raymond Chen is doing a great job at sharing interesting stories from a bygone era.
- criddell 4y ago
  Bygone? It's a fairly regular occurrence where I search for some Win32 API and end up on Chen's blog. I get what you are saying about articles like this one though. I can't imagine much new work is happening with the 8086 (or 8088 or '186 or '286 or ...)
  - GabrielTFS 4y ago
    I mean even w.r.t. Windows stuff, quite a large part of what he talks about is variations on "here's an interesting old anecdote from 1995" or "You know that thing that's totally useless now and doesn't matter ? Here's why we absolutely needed it in 1989."

hacknat 4y ago

My favorite Chen article: Why do Windows functions all begin with a pointless MOV EDI, EDI instruction? https://devblogs.microsoft.com/oldnewthing/20110921-00/?p=9583 https://devblogs.microsoft.com/oldnewthing/20110921-00/?p=95...

omnibrain 4y ago
It's such a shame that they killed (twice now?) all the comments in the blog.
- game-of-throws 4y ago
  They also changed the URL at least once and broke all links to it. His posts deserve better.
- password4321 4y ago
  Yes, I miss my weekly-ish from Raymond's arch nemesis Yuhong Bao. For this specific blog post there's an HN discussion¹ and archive.today² (beware!?³) did grab comments while the Internet Archive does not load them: ¹ https://news.ycombinator.com/item?id=3022224 https://news.ycombinator.com/item?id=3022224 ² http://archive.today/2015.07.08-134638/http://blogs.msdn.com/b/oldnewthing/archive/2011/09/21/10214405.aspx http://archive.today/2015.07.08-134638/http://blogs.msdn.com... ³ https://news.ycombinator.com/item?id=31945924#31946453 https://news.ycombinator.com/item?id=31945924#31946453
  - m463 4y ago
    nice use of superscripts
- mananaysiempre 4y ago
  There is a more-or-less comprehensive archive[1] up to 2019 (which should probably be scraped and hoarded). The article in question is there, comments included[2]. Side note: Michael Kaplan’s blog, which Microsoft took down in a remarkably shameful manner, has also been archived[3], while Eric Lippert reposted (most of?) his old articles on his personal WordPress instance[4]. [1] http://bytepointer.com/resources/old_new_thing/index.htm http://bytepointer.com/resources/old_new_thing/index.htm [2] http://bytepointer.com/resources/old_new_thing/20110921_226_why_do_windows_functions_all_begin_with_a_pointless_mov_edi_edi_instruction.htm http://bytepointer.com/resources/old_new_thing/20110921_226_... [3] http://archives.miloush.net/michkap/archive/ http://archives.miloush.net/michkap/archive/ [4] https://ericlippert.com/ https://ericlippert.com/

kazinator 4y ago

> "there was no room" They were saving it for 286, 386, ... MMX, AVX, SSE, ...

olliej 4y ago
x86 is variable length, and so extensions were able to use prefix bytes to distinguish them. On the plus side that means common instructions are still actually compact so reducing icache pressure.
- rep_lodsb 4y ago
  It's not so compact anymore! Using 64-bit registers, or any of R8-R15, requires a prefix byte. The single-byte INC/DEC opcodes have been repurposed for this. And for performance reasons having to do with how it affects the flags, you don't want to use INC/DEC (now two bytes) at all. So now the very common operation of incrementing a register takes at least three bytes, four if it needs the prefix. Legacy instructions have been made invalid - depending more on the whims of Intel/AMD than whether they are actually useful - but still clutter up the opcode space.
  - olliej 4y ago
    Obviously it has expanded, and not saying "let's completely replace the ISA in 64bit modes" means that a bunch of cruft is going to be consuming the ISA space. At the same time there is a lot of code that isn't using 64bit values so the compact coding can still be used. But while talking about ISA size and compactness, we need to compare to the real world alternative: the various ARM or RISC-V ISAs, etc are all 4byte per instruction with the occasional 2 byte variable length extensions*. 4 byte does seem to have been what has been selected for. My experience with code size is wrapped up in jitting JS so I could believe my experience isn't as reflective of real world code size as it could be :D * fun story: thumb2 had an early bug/errata where a 4 byte branch spanning a page boundary would jump to the wrong page.

aftbit 4y ago

>These redundant encodings are used by some assemblers to “fingerprint” their output. Fascinating! Does anyone have links to more information about this? What purpose might one have for this fingerprinting?

retrac 4y ago
If you sell a commercial compiler or assembler, and some company starts selling a product produced with your compiler/assembler, and you know you never sold them a license, you've got yourself someone to sue. For a less successful/commercial product, it could also just be for the joy of finding it used in the wild. Similar fingerprinting techniques were also used by assembly coders as proof of copyright. When reverse-engineering to a spec, it's not unusual for routines, even long routines, as well as lookup tables, etc. to end up being coded the same, or nearly so, as the original software. This isn't necessarily infringing of copyright -- for example there are only a few sensible ways to check if a character is uppercase in ASCII. It can be hard to tell reverse-engineered and re-implemented code, from disassembled and reshuffled code (which is copyright infringement). If the suspect routine incorporates something like an idiosyncratic sequence of NOPs that serve no particular purpose, coincidence is a lot harder to argue.
bell-cot 4y ago
One example (scroll down to 'Code fingerprint') - https://en.wikipedia.org/wiki/A86_(software) https://en.wikipedia.org/wiki/A86_(software)
- rep_lodsb 4y ago
  Can anyone find a version of A86 that actually encodes some information in its output, or is this just a legend? It produces different opcodes for some instructions than MASM, but so do DEBUG and various other assemblers. And the same instruction repeated multiple times always assembles to the same opcode as far as I have seen. To prove some program was made with A86, there would have to be a more specific signature that wouldn't match any other assembler, like a copyright message encoded bit-by-bit in the opcode choice.

Linda703 4y ago

[dead]

rep_lodsb 4y ago

IMO the base+index encoding (in 16-bit x86) was a mistake, it should have simply allowed indirection through any single register (+ immediate offset), including SP. • the address calculation would be simple enough to do hardwired even on the original 8086, instead of using slow microcode. The 8086 actually took a different amount of clock cycles depending on the registers used for base and index, because there wasn't enough ROM space to duplicate the code for every combination without using jumps! • you could use [SP+xxxx] to access local variables (frame pointer omission) • would be able to emulate the 8080's LDAX/STAX and XTHL in a single instruction • with so few registers, you really want every one available for memory addressing. Especially AX which is used implicitly by instructions like LODSW and MUL.

AceJohnny2 4y ago
That would require additional transistors/surface, which was at a premium. The 8086 was designed under harsh technical constraints by moderns standards. Don't forget that.
- AceJohnny2 4y ago
  TBH I'm still flabbergasted that modern SoCs will "just put a CPU there" rather than a DMA, because we can actually afford it. 6502 cores are sprinkled around like fairy dust.
  - jffry 4y ago
    The FPGA dev boards I worked with in a college course circa 2009 had a couple of PowerPC cores thrown in as a bonus, with a whole system for being able to interface between CPU and FPGA: https://www.xilinx.com/content/dam/xilinx/support/documents/ip_documentation/ppc440_virtex5.pdf https://www.xilinx.com/content/dam/xilinx/support/documents/...
    - deelowe 4y ago
      It's still common today. The de-10 nano of mister fame leverages the hard processor to great affect.

VogonPoetry 4y ago

Given that the 8086 has SI and DI with a +imm8 mode, like the (IX+imm8) and (IY+imm8) instructions on the Z80. I do wonder if Z80 CP/M machines were the real target rather than the 8080. I did write an 8086 assembly based Z80 emulator (in the late 80's) that was surprisingly compact and had acceptable Z80 performance on a 12MhZ AMD 80286. It passed CP/M system calls to Concurrent DOS. I should see if I still have the code and run an emulator torture test to see how bad it was.

rep_lodsb 4y ago
Too bad that you need SI for the program counter, and DI to emulate some addressing modes that the 8080 could do but x86 can't. Even if translating code ahead of time, "LD (BC), A" needs to be emulated as something like "MOV DI,CX; MOV [DI],AL".
- VogonPoetry 4y ago
  I went and found my code, with a side trip into being able to "unzoo" the archive! Yes, I agree. I also used SI as the PC so I could use "lodsb" (cute HN name BTW) and "lodsw" for 2 byte args. My register use was 286 Z80 --- --- BX HL CX BC DX DE DI A SI PC When emulating the DD, FD and CB prefixes I pre-loaded BP with either IX+d, IY+d (IX, IY were stored in memory) or BX and jumping to common code. Basic structure was like OP_00: XOR AH,AH LODSB SHL AX,1 MOV BP,AX JMP CS:OP_table[BP] For OP_02 - "LD (BC),A" I used, OP_02: XCHG CX,DI MOV [DI], CL XCHG CX,DI JMP OP_00 I did see some opportunities for additional code-golf. Also noticed that EX AF,AF' did not properly exchange the flags (so that will need to get fixed!). I was mostly only running m80, l80 and mload.

quickthrower2 4y ago

Suggestion: Remove the “Yes, “ and “, but” from the title to make it more HN-ish.

rep_lodsb 4y ago
Memory safety should have been more a concern for the design of the 8086! And if 8080 backwards compatibility is really necessary, we can write an emulator in Rust, compiled to WebAssembly and running on RISC-V. /s

JadeNB 4y ago

I thought the trailing-off title was some sort of clickbait (which would be weird for Chen!); but actually the title is "Yes, the 8086 wanted to be mechanically translatable from the 8080, but why not add the ability to indirect through AX, CX and DX?", and I guess it just got asemantically chopped on HN's end. (To avoid my own clickbait, the one-sentence answer from the article, on which of course the rest of the article elaborates, is "Basically, because there was no room.")

sharmin123 4y ago