Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Understanding x86 instruction encoding is far better done in octal --- you can memorise most of the instruction set this way: https://news.ycombinator.com/item?id=30409100

Of course, IMO the 64-bit extension by AMD that followed it was far messier.



Author here. Thanks for the link! I added the "x86 Is an Octal Machine" link, quoting your comment, in the end of my "encoding resources" post here: https://blog.kenanb.com/code/low-level/2024/01/07/x86-insn-e...

I have also been referencing that document since I started writing on the topic: https://blog.kenanb.com/code/low-level/2024/01/04/x86-insn-e...

It really helps reasoning about the encoding, but as you pointed out, x64 extension makes it challenging. I basically end up switching between octal and hex, depending on the byte, during the process.


I suspect it's similar to the 6502, picking the right arrangement and grouping of bits will make the patterns more apparent. The 6502 has a much more limited set of instructions, but here's an example of changing the arrangement [1].

[1] https://www.nesdev.org/wiki/CPU_unofficial_opcodes


Another note on this topic that in hindsight, should have been obvious, but it got me confused at the time:

Just trying to dump the whole (or large parts of the) instruction in octal will make things much more confusing. That's not what's meant by the "x86 is an octal machine" statement.

It is only individual bytes, and only certain bytes, of the instruction the should be "separately" printed in octal, to make certain patterns easier to read. If you try to print a group of bytes in octal at once, irrelevant information from adjacent byte will be bundled into a single octal digit.


The pdp-11 was also an "octal machine" and it was clear from all the documentation that it was.

When did the switch to hex happen?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: