x86 Is an Octal Machine (1995)
gist.github.com
x86 Is an Octal Machine (1995)
1–10 of 51 posts
Re: x86 Is an Octal Machine (1995)
#2All of these are features inherited from the 8080/8085/Z80.
Here are the corresponding opcode tables in octal:
https://dercuano.github.io/notes/8080-opcode-map.html
http://www.righto.com/2013/02/8085-instruction-set-octal-tab...
Re: x86 Is an Octal Machine (1995)
#3This is an old article from the early 90s and I believe it may have been the first public mention of this fact about the x86 encoding, although no doubt many have independently "discovered" it before --- especially in the times when microcomputer programming consisted largely of writing down Asm on paper and then hand-assembling the bytes into memory using something like a hex keypad. All of these are features inheri…
Astonishing to think that we can see traces of the 8008 still today and that it wasn’t actually an Intel designed ISA (came from CTC / Datapoint).
Re: x86 Is an Octal Machine (1995)
#4The "core" (non-E/VEX, non-SSE, etc.) x86 encoding is wonderfully clever and terrible by modern standards, and Volume 2 of Intel's SDM is a great reference for how x86 manages to pack remarkably complicated addressing, operand, etc. semantics into just a handful of bytes. The result is a format that's remarkably hard to decode correctly, meaning that just about every software decoder for x86 is saturated with bugs[1] (FD: my project).
Re: x86 Is an Octal Machine (1995)
#5I remember seeing a copy of this Usenet post years ago! It's one of my favorite "secrets" about x86's encoding. The "core" (non-E/VEX, non-SSE, etc.) x86 encoding is wonderfully clever and terrible by modern standards, and Volume 2 of Intel's SDM is a great reference for how x86 manages to pack remarkably complicated addressing, operand, etc. semantics into just a handful of bytes. The result is a format that's remar…
Re: x86 Is an Octal Machine (1995)
#6That's a backwards way of saying it. I'd rather say, given the hardware structure of the bit fields of the opcode register, the binary opcodes are perhaps better described by octal notation rather than hexadecimal.
Re: x86 Is an Octal Machine (1995)
#7This is an old article from the early 90s and I believe it may have been the first public mention of this fact about the x86 encoding, although no doubt many have independently "discovered" it before --- especially in the times when microcomputer programming consisted largely of writing down Asm on paper and then hand-assembling the bytes into memory using something like a hex keypad. All of these are features inheri…
Re: x86 Is an Octal Machine (1995)
#8I remember seeing a copy of this Usenet post years ago! It's one of my favorite "secrets" about x86's encoding. The "core" (non-E/VEX, non-SSE, etc.) x86 encoding is wonderfully clever and terrible by modern standards, and Volume 2 of Intel's SDM is a great reference for how x86 manages to pack remarkably complicated addressing, operand, etc. semantics into just a handful of bytes. The result is a format that's remar…
I haven't seen the FD abbreviation, is it "full disclosure" ?
Re: x86 Is an Octal Machine (1995)
#9> ALL 80x86 OPCODES ARE CODED IN OCTAL That's a backwards way of saying it. I'd rather say, given the hardware structure of the bit fields of the opcode register, the binary opcodes are perhaps better described by octal notation rather than hexadecimal.
Re: x86 Is an Octal Machine (1995)
#10> ALL 80x86 OPCODES ARE CODED IN OCTAL That's a backwards way of saying it. I'd rather say, given the hardware structure of the bit fields of the opcode register, the binary opcodes are perhaps better described by octal notation rather than hexadecimal.
I can't interpret the author's intent, but I think they're trying to point out a conflict between how Intel and most other references document the x86 opcode byte (as a byte table, with no clear coordinate relation between bits) versus how the byte is structured internally (around octal values, which would reveal a coordinate relationship if visualized).
I wouldn't say there's any "conflict". Who needs to know the detailed hardware structure? Compiler writers maybe, but they experience and order of magnitude more conflicts then.