https://devblogs.microsoft.com/oldnewthing/20220725-00/?p=106889 Skip to main content [RE1Mu3b] Microsoft The Old New Thing The Old New Thing The Old New Thing * Home * DevBlogs * Developer + Visual Studio + Visual Studio Code + Visual Studio for Mac + DevOps + Developer support + CSE Developer + Engineering@Microsoft + Azure SDK + IoT + Command Line + Perf and Diagnostics + Dr. International + Notification Hubs + Math in Office * Technology + DirectX + PIX + SurfaceDuo + Startups + Sustainable Engineering + Windows AI Platform * Languages + C++ + C# + F# + Visual Basic + TypeScript + PowerShell Community + PowerShell Team + Python + Q# + JavaScript + Java + Java Blog in Chinese * .NET + .NET + .NET MAUI + Blazor + ASP.NET + NuGet + Xamarin * Platform Development + #ifdef Windows + Apps for Windows + Azure Depth Platform + Azure Government + Bing Dev Center + Microsoft Edge Dev + Microsoft Azure + Microsoft 365 Developer + Old New Thing + Windows MIDI and Music dev + Windows Search Platform * Data Development + Azure Cosmos DB + Azure Data Studio + Azure SQL Database + OData + Revolutions R + SQL Server Data Tools * More [ ] Search Search Cancel Yes, the 8086 wanted to be mechanically translatable from the 8080, but why not add the ability to indirect through AX, CX and DX? [png] Raymond Chen July 25th, 20226 Some time ago, I noted that the 8086 was designed so that existing 8080 code could be machine-translated instruction by instruction into 8086. The 8086 BX register stood in for the HL register pair on the 8080, and it is also the only register that you could indirect through, mirroring the corresponding limitation on the 8080. But that explains only part of the story. Yes, the 8086 had to let you indirect through BX so that 8080 instructions which operate on M (which was the pseudo-register that represented [HL]) could be translated into operations on [BX]. But that doesn't mean that the 8086 had to forbid indirection through the other registers. After all, the 8086 had plenty of other instructions that didn't exist on the 8080. So you can't take away BX, but more is better, right? Why didn't the 8086 let you indirect through AX, CX or DX, as well as BX? Basically, because there was no room. The encoding of two-operand instructions on the 8086 went like this: 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 op d w mod reg r/m The op determines the operation to be performed. The d is the direction (reg to r/m or r/m to reg).1 The w indicates whether it is a byte operation or a word operation. The mod is the mode and describes how the r/m is to be interpreted. The reg is the first operand, always a register (although the d bit can reverse the first and second operands). The interesting thing here is the mod + r/m combination, since those capture the possible memory operands. +-------------------------------------------------------------------+ | | mode+w | | r/m |-------------------------------------------------------------| | | 00+* | 01+* | 10+* | 11+0 | 11+1 | |-----+------------+----------------+-----------------+------+------| | 000 | * PTR | * PTR | * PTR | AL | AX | | | [BX+SI] | [BX+SI+imm8] | [BX+SI+imm16] | | | |-----+------------+----------------+-----------------+------+------| | 001 | * PTR | * PTR | * PTR | CL | CX | | | [BX+DI] | [BX+DI+imm8] | [BX+DI+imm16] | | | |-----+------------+----------------+-----------------+------+------| | 010 | * PTR | * PTR | * PTR | DL | DX | | | [BP+SI] | [BP+SI+imm8] | [BP+SI+imm16] | | | |-----+------------+----------------+-----------------+------+------| | 011 | * PTR | * PTR | * PTR | BL | BX | | | [BP+DI] | [BP+DI+imm8] | [BP+DI+imm16] | | | |-----+------------+----------------+-----------------+------+------| | 100 | * PTR [SI] | * PTR | * PTR | AH | SP | | | | [SI+imm8] | [SI+imm16] | | | |-----+------------+----------------+-----------------+------+------| | 101 | * PTR [DI] | * PTR | * PTR | CH | BP | | | | [DI+imm8] | [DI+imm16] | | | |-----+------------+----------------+-----------------+------+------| | 110 | imm | * PTR | * PTR | DH | SI | | | | [BP+imm8] | [BP+imm16] | | | |-----+------------+----------------+-----------------+------+------| | 111 | * PTR [BX] | * PTR | * PTR | BL | DI | | | | [BX+imm8] | [BX+imm16] | | | +-------------------------------------------------------------------+ The encoding leaves room for 8 memory addressing modes. We are forced to have [BX] for compatibility, but we can choose the other seven. You need to be able to indirect through the base pointer so that you can access your local variables and parameters. And it's expected that you can indirect through SI and DI since those are the registers used for block memory operations. That leaves four more addressing modes, and the architects decided to use the four ways of combining BX/BP with SI/DI. The BP+x addressing modes let you access arrays on the stack, and the BX+x addressing modes let you access arrays on the heap, where SI and DI serve as the index registers. Now, the architects could have chosen to allow indirection through the other three 16-bit registers, but that would have left room for only one array indexing mode. Giving the instructions to the array indexing modes means that you lose [AX], [CX], and [DX], but that's less of a loss because you can still indirect through [SI] and [DI] (and [BP], but that's intended to be the frame pointer, not a general-purpose pointer register). The other choice would be to increase the number of addressing modes by going to a three-byte instruction encoding, thereby picking up eight more bits. But that seems like quite an excessive step, seeing as the original 8080 consisted only of one-byte instructions. (I'm not counting immediate bytes toward encoding counts for the purpose of this comparison.) It was a game of trade-offs, and the trade-off was to pick up indexed addressing, and give up on supporting indirection through all of the 16-bit registers. 1 Note that this means that register-to-register operations can be encoded two ways: 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 op 0 w 1 1 reg1 reg2 op 1 w 1 1 reg2 reg1 These redundant encodings are used by some assemblers to "fingerprint" their output. [png] Raymond Chen Follow Tagged History Read next How to write like Raymond: Contacting another team for the first time Flattery will get you in the door. [png]Raymond Chen June 7, 2022 9 comments Be careful with that thing, it's a confidential coffee maker Just keep it under wraps. [png]Raymond Chen April 26, 2022 9 comments 6 comments Leave a commentCancel reply Log in to join the discussion. * [png] rhoffmann08 July 25, 2022 8:20 am collapse this comment Could they have made the bit fields variable, depending on "op"? For example, as you said, "d" wasn't required for register-to-register copies. Log in to Reply + [png] Antonio Rodriguez July 25, 2022 8:42 am collapse this comment Theoretically, it would have been possible. But in practice, there would have been two problems. First, encoding parameters in the same way for several opcodes allows you to use the same decoding/fetching circuitry for most move and ALU instructions. In those days, a lower transistor count would mean greater product yields and lower prices. That's why the 6502 totally eclipsed Motorola's 6800: it had the lowest transistor count, and thus on launch it was also the cheapest processor, by a wide margin. Second, having different addressing modes available in different instructions is a very bad idea when you hand write assembly code, which was usual at the time. The 6502 suffered this, but it was almost bearable because its instruction set was small and there weren't many exceptions, so you learned them after some time. The 8086 had a much larger instruction set, which would have made it painful. In fact, when the 68000 arrived, it was usually praised for the orthogonality of its instruction set (compared with that of the 8086, that is, which in itself was much more uniform than the 8080 it replaced). Log in to Reply o [png] Simon Farnsworth July 25, 2022 9:41 am collapse this comment As a historical note, it's worth remembering that the iAPX 432 was the design that was getting all the attention at Intel; it started before the 8086 did. The 8086 was meant as a stop-gap to allow existing 8080 and 8085 customers to move into the 16 bit world easily, while the iAPX 432 was going to be the next big leap. And the iAPX 432 had variable length instructions - 6 bits for the shortest, 321 bits for the longest - that didn't need to be byte aligned, so it didn't have this specific issue. So one of the issues that you'd have trying to get the 8086 to use more complex decode is that it's the stop-gap; the thing you're releasing not because it's meant to take over the world (that's the iAPX 432), but the thing you're releasing so that the world will wait for the next big thing. Log in to Reply # [png] Pete Nelson July 25, 2022 1:56 pm collapse this comment Kind of like how IA-64 was going to take over the 64-bit world, but AMD64 came in with an easier migration path and ate IA-64's lunch... Log in to Reply # [png] Antonio Rodriguez July 25, 2022 3:02 pm collapse this comment Well, the iAPX failed precisely because it was too complex for the technology of the time. It had to be broken in two ICs (ALU and control unit), simply because they couldn't put enough transistors in a single state-of-the-art die. That drove the costs through the ceiling and hindered the communication speed between both units, which resulted in a system that was incompatible, very expensive, and just a hair more powerful than the 8086 (and slower than Motorola's 68000). The iAPX was, in many ways, decades ahead of its time - and also decades ahead of the technology needed to build it. Log in to Reply * [png] Sukru Tikves July 25, 2022 10:16 am collapse this comment Is BH being missing a typo? In column "11+0" Log in to Reply Archive July 2022 June 2022 May 2022 April 2022 March 2022 February 2022 January 2022 December 2021 November 2021 October 2021 September 2021 August 2021 July 2021 June 2021 May 2021 April 2021 March 2021 February 2021 January 2021 December 2020 November 2020 October 2020 September 2020 August 2020 July 2020 June 2020 May 2020 April 2020 March 2020 February 2020 January 2020 December 2019 November 2019 October 2019 September 2019 August 2019 July 2019 June 2019 May 2019 April 2019 March 2019 February 2019 January 2019 December 2018 November 2018 October 2018 September 2018 August 2018 July 2018 June 2018 May 2018 April 2018 March 2018 February 2018 January 2018 December 2017 November 2017 October 2017 September 2017 August 2017 July 2017 June 2017 May 2017 April 2017 March 2017 February 2017 January 2017 December 2016 November 2016 October 2016 September 2016 August 2016 July 2016 June 2016 May 2016 April 2016 March 2016 February 2016 January 2016 December 2015 November 2015 October 2015 September 2015 August 2015 July 2015 June 2015 May 2015 April 2015 March 2015 February 2015 January 2015 December 2014 November 2014 October 2014 September 2014 August 2014 July 2014 June 2014 May 2014 April 2014 March 2014 February 2014 January 2014 December 2013 November 2013 October 2013 September 2013 August 2013 July 2013 June 2013 May 2013 April 2013 March 2013 February 2013 January 2013 December 2012 November 2012 October 2012 September 2012 August 2012 July 2012 June 2012 May 2012 April 2012 March 2012 February 2012 January 2012 December 2011 November 2011 October 2011 September 2011 August 2011 July 2011 June 2011 May 2011 April 2011 March 2011 February 2011 January 2011 December 2010 November 2010 October 2010 September 2010 August 2010 July 2010 June 2010 May 2010 April 2010 March 2010 February 2010 January 2010 December 2009 November 2009 October 2009 September 2009 August 2009 July 2009 June 2009 May 2009 April 2009 March 2009 February 2009 January 2009 December 2008 November 2008 October 2008 September 2008 August 2008 July 2008 June 2008 May 2008 April 2008 March 2008 February 2008 January 2008 December 2007 November 2007 October 2007 September 2007 August 2007 July 2007 June 2007 May 2007 April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 November 2003 October 2003 September 2003 August 2003 July 2003 Relevant Links I wrote a book Ground rules Disclaimers and such My necktie's Twitter Categories Code History Tips/Support Other Non-Computer Stay informed Login Insert/edit link Close Enter the destination URL URL [ ] Link Text [ ] [ ] Open link in a new tab Or link to existing content Search [ ] No search term specified. Showing recent items. Search or use up and down arrow keys to select an item. Cancel [Add Link] Code Block x Paste your code snippet [ ] Cancel Ok What's new * Surface Pro 8 * Surface Laptop Studio * Surface Pro X * Surface Go 3 * Surface Duo 2 * Surface Pro 7+ * Windows 11 apps * HoloLens 2 Microsoft Store * Account profile * Download Center * Microsoft Store support * Returns * Order tracking * Virtual workshops and training * Microsoft Store Promise * Flexible Payments Education * Microsoft in education * Devices for education * Microsoft Teams for Education * Microsoft 365 Education * Education consultation appointment * Educator training and development * Deals for students and parents * Azure for students Business * Microsoft Cloud * Microsoft Security * Azure * Dynamics 365 * Microsoft 365 * Microsoft Advertising * Microsoft Industry * Microsoft Teams Developer & IT * Developer Center * Documentation * Microsoft Learn * Microsoft Tech Community * Azure Marketplace * AppSource * Microsoft Power Platform * Visual Studio Company * Careers * About Microsoft * Company news * Privacy at Microsoft * Investors * Diversity and inclusion * Accessibility * Security English (United States) * Sitemap * Contact Microsoft * Privacy * Manage cookies * Terms of use * Trademarks * Safety & eco * About our ads * (c) Microsoft 2022