Because the Intel 8080 instruction set was octal, right?
This is cool: https://dercuano.github.io/notes/8080-opcode-map.html
x86 Is an Octal Machine (1995)
11–20 of 51 posts
Re: x86 Is an Octal Machine (1995)
#12This 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…
Thanks for these links - very interesting. 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).
The Datapoint 2200, the source of the 8008 instruction set, is an interesting machine. The CPU was built from TTL chips. To decode instructions, they used decimal BCD decoder chips, specifically the 7442. But they'd use them as octal decoder chips, only using 8 outputs.
The Datapoint 2200 documentation gave the opcodes in octal, so they were clearly thinking in octal. The 8008 documentation, however, didn't use octal or hexadecimal. The opcodes were given in binary, but grouped in 3 bits, octal style, e.g. 10 111 010. (They didn't specify opcodes in octal or hex!) I think the 8008 was right at the time where octal was on the way out and hexadecimal was taking over. (The 8008 assembler manual uses both octal and hexadecimal, but hexadecimal primarily.)
The Intel 8080 still specified the instruction set in binary, not octal or hexadecimal. The 8085 had opcodes in binary in a 1983 manual, but now split with a line into 4-bit chunks (i.e. hexadecimal-style). And then an appendix gave the opcodes in hexadecimal.
(Just some random history.)
Re: x86 Is an Octal Machine (1995)
#13Earlier quoted context omitted.
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).
Exactly. Then there's no need to scream an odd headline. 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.
> Who needs to know the detailed hardware structure? Compiler writers maybe, but they experience and order of magnitude more conflicts then.
I think this Usenet posting was written in the early 1990s, when a large number of people were probably still using macro assemblers to write large programs, and may have also been writing binary patches for those programs back when that was easier (no relocations to worry about!). It's definitely more of a "cool fact" than something you'd immediately apply, but it's the kind of thing I could see being useful to an assembly programmer of the period.
For my N=1 experience: I've written compact x86 decoders in HDLs before, and this octal mapping of the opcode structure was extremely useful in helping me determine an optimal (in terms of minimal gate counts) decoder structure. But that is indeed a very niche use case.
Re: x86 Is an Octal Machine (1995)
#14Earlier quoted context omitted.
Exactly. Then there's no need to scream an odd headline. 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.
> Who needs to know the detailed hardware structure? Compiler writers maybe, but they experience and order of magnitude more conflicts then. I think this Usenet posting was written in the early 1990s, when a large number of people were probably still using macro assemblers to write large programs, and may have also been writing binary patches for those programs back when that was easier (no relocations to worry about…
I was there. I've done my share of programming in assembler and building hardware for embedded systems. I certainly needed to know the hardware details, but I never saw a need to rewrite the opcodes in another notation.
I definitely appreciate the point of your last paragraph.
Re: x86 Is an Octal Machine (1995)
#15I 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…
In my experience it's the "second page" of opcodes (0f xx) where the difficulty lies; the first page has been thoroughly explored and documented by now.
Historical note: the 286 was the first to have the second page.
Re: x86 Is an Octal Machine (1995)
#16I 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…
Seeing that reminds me of one of the projects I want to do: the "World's Worst x86 Decoder". The basic idea is you toss most of the x86 manual, and just consider all of the prefixes as part of the opcode, so you say that x86 has (numbers are top of head, may be inaccurate) N opcodes, where N = 256 * 4 opcode maps * 4 group 1 prefix possibilities * 7 group 2 prefix * 2 group 3 * 2 group 4 * {REX/VEX/EVEX prefix counting is hard to do). It's the "world's worst" decoder, because not only does it not try to actually give a human-readable name for the opcode, it is also going to give patently wrong results for cases where "we packed 8 different instructions into this opcode, because they each take a memory argument, so the other R field in the ModR/M byte chooses a different instruction".
Re: x86 Is an Octal Machine (1995)
#17Earlier quoted context omitted.
Thanks for these links - very interesting. 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).
The Datapoint 2200, the source of the 8008 instruction set, is an interesting machine. The CPU was built from TTL chips. To decode instructions, they used decimal BCD decoder chips, specifically the 7442. But they'd use them as octal decoder chips, only using 8 outputs. The Datapoint 2200 documentation gave the opcodes in octal, so they were clearly thinking in octal. The 8008 documentation, however, didn't use octal…
Do you know if Federico Faggin copied the logic design of the 2200 or implemented the ISA using his own design?
Re: x86 Is an Octal Machine (1995)
#18The x86 is an enhancement of the 8-bit 8080. That also was an octal machine.
Re: x86 Is an Octal Machine (1995)
#19This 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…
I kind of doubt it was actually the first. It's definitely an interesting/cute thing to notice and write up but I think the weird longevity of this particular piece owes more to the pioneering clickbaity framing (x86 is not really an octal machine, it's not surprising that people 'hadn't noticed' because obviously they had, etc) than the observations themselves.
The sibling comments disagree with you
Re: x86 Is an Octal Machine (1995)
#20Earlier quoted context omitted.
I kind of doubt it was actually the first. It's definitely an interesting/cute thing to notice and write up but I think the weird longevity of this particular piece owes more to the pioneering clickbaity framing (x86 is not really an octal machine, it's not surprising that people 'hadn't noticed' because obviously they had, etc) than the observations themselves.
The sibling comments disagree with you
I’m not seeing any disagreement in sibling or other comments