Intel's IA32/64 bit architecture's instruction set encoding

[postaquestion]

I'm contacting you in referenceto the "Intel 64 and IA-32 Architectures Software Developers Manual" document volume 2B (#253667), appendix B.

I'm currently coding a disassembler, and while studying the instruction set opcode encoding I've noticed a resemblance of bits encoding between different, yet similar instructions.

For example, I found that in some of the 0x0? single byte instructions, when the sixth byte equals 1 and the fifth 0, a direct reference to AL/AX/EAX is being made.

Another repetitive pattern I noticed is that in the shift/rotate instructions: the seventh bit determines the usage of the CL register, I also noticed a relevance of the fourth bit - it determines, if equals 1, a pre-defined factor - cl register, 1 bit rotation, or, if equals 0, an imm8 data reference. Some of these, and more, also repeat in other instructions as well.

I wondered if there is a manual/resource/index that defineslists these encodings that you could refer me to, as I'm interested in the listing for my project and general understanding. I also wish, if possible, a clarification for the reserved values in some of the bits in some ModRM bytes(usually reg1 - RCL for example, reserves 010b)

[TimP]

If you are writing your software under GPL license, you can make use of what is in gnu binutils. Otherwise, I think you will have a steeper learning curve.

[SHIH_K_Intel]

Your observation ofcertain patterns is a reflection of several evolving design considerations that applied to earlier times in the progression of Moore's law on microprocessor architecture.

There are many technical and non-technical factors that influence the selection of instruction syntax and instruction encoding scheme for newer instructions. Those factors change over time, what may be important in the days when one-byte-opcode instructions were architected may be less relevant now with more transistors available for processor logic.

It may be an interesting topic as a historical write up, but the safer way for a disassembler tool is a factual approach of what's presented in chapter 2 and Section 3.1 of Vol. 2A, instead of trying to extrapolate a theorem from phenomenological data in one or two tables in appendix B.

[vid512]

You can find handy quick instruction reference here: http://ref.x86asm.net/

Links to several editions are at the bottom of page. It also contains XML list of instruction, and I think author intended this to be complete enough to somehow generate disassembler from it.

If you want easy-to-use portable x86 disassembler with nice (BSD) licence, my suggestion would be diStorm:
http://www.ragestorm.net/distorm/

[AFog0]

vid512:

If you want easy-to-use portable x86 disassembler with nice (BSD) licence, my suggestion would be diStorm: http://www.ragestorm.net/distorm/

Or objconv. www.agner.org/optimize/objconv.zip. Open source, supports latest instruction sets, all operating systems and file formats.