{"id":106889,"date":"2022-07-25T07:00:00","date_gmt":"2022-07-25T14:00:00","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/oldnewthing\/?p=106889"},"modified":"2022-11-30T06:43:28","modified_gmt":"2022-11-30T14:43:28","slug":"20220725-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20220725-00\/?p=106889","title":{"rendered":"Yes, the 8086 wanted to be mechanically translatable from the 8080, but why not add the ability to indirect through AX, CX and DX?"},"content":{"rendered":"

Some time ago, I noted that the 8086 was designed so that existing 8080 code could be machine-translated instruction by instruction into 8086<\/a>. The 8086 BX<\/code> register stood in for the HL<\/code> register pair on the 8080, and it is also the only register that you could indirect through, mirroring the corresponding limitation on the 8080.<\/p>\n

But that explains only part of the story. Yes, the 8086 had to let you indirect through BX<\/code> so that 8080 instructions which operate on M<\/code> (which was the pseudo-register that represented [HL]<\/code>) could be translated into operations on [BX]<\/code>. 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.<\/p>\n

So you can’t take away BX<\/code>, but more is better, right? Why didn’t the 8086 let you indirect through AX<\/code>, CX<\/code> or DX<\/code>, as well as BX<\/code>?<\/p>\n

Basically, because there was no room.<\/p>\n

The encoding of two-operand instructions on the 8086 went like this:<\/p>\n\n\n\n\n
7<\/th>\n6<\/th>\n5<\/th>\n4<\/th>\n3<\/th>\n2<\/th>\n1<\/th>\n0<\/th>\n <\/td>\n7<\/th>\n6<\/th>\n5<\/th>\n4<\/th>\n3<\/th>\n2<\/th>\n1<\/th>\n0<\/th>\n<\/tr>\n
op<\/td>\nd<\/td>\nw<\/td>\n <\/td>\nmod<\/td>\nreg<\/td>\nr\/m<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The op<\/code> determines the operation to be performed.<\/p>\n

The d<\/code> is the direction (reg to r\/m or r\/m to reg).\u00b9<\/p>\n

The w<\/code> indicates whether it is a byte operation or a word operation.<\/p>\n

The mod<\/code> is the mode<\/i> and describes how the r\/m<\/code> is to be interpreted.<\/p>\n

The reg<\/code> is the first operand, always a register (although the d<\/code> bit can reverse the first and second operands).<\/p>\n

The interesting thing here is the mod<\/code> + r\/m<\/code> combination, since those capture the possible memory operands.<\/p>\n\n\n\n\n\n\n\n\n\n\n\n\n
r\/m<\/th>\nmode+w<\/th>\n<\/tr>\n
00+*<\/th>\n01+*<\/th>\n10+*<\/th>\n11+0<\/th>\n11+1<\/th>\n<\/tr>\n
000<\/td>\n* PTR [BX+SI]<\/td>\n* PTR [BX+SI+imm8]<\/td>\n* PTR [BX+SI+imm16]<\/td>\nAL<\/td>\nAX<\/td>\n<\/tr>\n
001<\/td>\n* PTR [BX+DI]<\/td>\n* PTR [BX+DI+imm8]<\/td>\n* PTR [BX+DI+imm16]<\/td>\nCL<\/td>\nCX<\/td>\n<\/tr>\n
010<\/td>\n* PTR [BP+SI]<\/td>\n* PTR [BP+SI+imm8]<\/td>\n* PTR [BP+SI+imm16]<\/td>\nDL<\/td>\nDX<\/td>\n<\/tr>\n
011<\/td>\n* PTR [BP+DI]<\/td>\n* PTR [BP+DI+imm8]<\/td>\n* PTR [BP+DI+imm16]<\/td>\nBL<\/td>\nBX<\/td>\n<\/tr>\n
100<\/td>\n* PTR [SI]<\/td>\n* PTR [SI+imm8]<\/td>\n* PTR [SI+imm16]<\/td>\nAH<\/td>\nSP<\/td>\n<\/tr>\n
101<\/td>\n* PTR [DI]<\/td>\n* PTR [DI+imm8]<\/td>\n* PTR [DI+imm16]<\/td>\nCH<\/td>\nBP<\/td>\n<\/tr>\n
110<\/td>\nimm<\/td>\n* PTR [BP+imm8]<\/td>\n* PTR [BP+imm16]<\/td>\nDH<\/td>\nSI<\/td>\n<\/tr>\n
111<\/td>\n* PTR [BX]<\/td>\n* PTR [BX+imm8]<\/td>\n* PTR [BX+imm16]<\/td>\nBL<\/td>\nDI<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

The encoding leaves room for 8 memory addressing modes. We are forced to have [BX]<\/code> 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<\/code> and DI<\/code> since those are the registers used for block memory operations.<\/p>\n

That leaves four more addressing modes, and the architects decided to use the four ways of combining BX<\/code>\/BP<\/code> with SI<\/code>\/DI<\/code>. The BP+x<\/code> addressing modes let you access arrays on the stack, and the BX+x<\/code> addressing modes let you access arrays on the heap, where SI<\/code> and DI<\/code> serve as the index registers.<\/p>\n

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]<\/code>, [CX]<\/code>, and [DX]<\/code>, but that’s less of a loss because you can still indirect through [SI]<\/code> and [DI]<\/code> (and [BP]<\/code>, but that’s intended to be the frame pointer, not a general-purpose pointer register).<\/p>\n

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.)<\/p>\n

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.<\/p>\n

\u00b9 Note that this means that register-to-register operations can be encoded two ways:<\/p>\n\n\n\n\n\n
7<\/th>\n6<\/th>\n5<\/th>\n4<\/th>\n3<\/th>\n2<\/th>\n1<\/th>\n0<\/th>\n <\/td>\n7<\/th>\n6<\/th>\n5<\/th>\n4<\/th>\n3<\/th>\n2<\/th>\n1<\/th>\n0<\/th>\n<\/tr>\n
op<\/td>\n0<\/td>\nw<\/td>\n <\/td>\n1<\/td>\n1<\/td>\nreg1<\/td>\nreg2<\/td>\n<\/tr>\n
op<\/td>\n1<\/td>\nw<\/td>\n <\/td>\n1<\/td>\n1<\/td>\nreg2<\/td>\nreg1<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

These redundant encodings are used by some assemblers to “fingerprint” their output.<\/p>\n","protected":false},"excerpt":{"rendered":"

So many addressing modes, so little space.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[2],"class_list":["post-106889","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-history"],"acf":[],"blog_post_summary":"

So many addressing modes, so little space.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106889","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=106889"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/106889\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=106889"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=106889"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=106889"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}