[woodruffw]

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).

[jonsen]

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.

[woodruffw]

> 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.

[jonsen]

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.