Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

x86 Disassembly

en.wikibooks.org

Post reply on HN
Print view View original

21–29 of 29 posts

Re: x86 Disassembly

#21

Post by tptacek »

userbinator wrote: post #20
tptacek wrote: post #2

Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.

It's also much easier to decode x86 instructions when you look at them in octal instead of the hexadecimal that most tables use, since both the main opcode map and ModRM/SIB are organised in a 2-3-3 layout: http://reocities.com/SiliconValley/heights/7052/opcode.txt The 8080/8085/Z80 instruction sets also look much better in octal: http://www.z80.info/decoding.htm

I had no idea! This is very cool.

Re: x86 Disassembly

#22

Post by 101914 »

userbinator wrote: post #20
tptacek wrote: post #2

Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.

It's also much easier to decode x86 instructions when you look at them in octal instead of the hexadecimal that most tables use, since both the main opcode map and ModRM/SIB are organised in a 2-3-3 layout: http://reocities.com/SiliconValley/heights/7052/opcode.txt The 8080/8085/Z80 instruction sets also look much better in octal: http://www.z80.info/decoding.htm

This comment validates all the time I have "wasted" reading HN over the years.

It does not suprise me that something so simple would be so well overlooked (or, at least, "forgotten"). I wonder if I ever would have figured this out from my own readings and experiments. Doubtful.

Great tip!

Re: x86 Disassembly

#23

Post by tptacek »

tptacek wrote: post #21
userbinator wrote: post #20

Earlier quoted context omitted.

It's also much easier to decode x86 instructions when you look at them in octal instead of the hexadecimal that most tables use, since both the main opcode map and ModRM/SIB are organised in a 2-3-3 layout: http://reocities.com/SiliconValley/heights/7052/opcode.txt The 8080/8085/Z80 instruction sets also look much better in octal: http://www.z80.info/decoding.htm

I had no idea! This is very cool.

This is seriously exploding my brain. Thank you for posting it.

Re: x86 Disassembly

#24

Post by ianopolous »

mschuster91 wrote: post #9
tptacek wrote: post #2

Write a disassembler at least once. It's much easier than you think it is (even with X86) --- it's essentially a file format parser --- and very illuminating.

I'm currently writing one in JavaScript of all languages, just to prove it works. also, it's true multi-platform ;)

You may find this disassembler port to Java I did useful. [JayD](http://github.com/ianopolous/JayD) it's more accurate than both objdump and its source, udis86, after I used it as the base for the [JPC emulator](http://github.com/ianopolous/JPC).

Re: x86 Disassembly

#25

Post by userbinator »

101914 wrote: post #22
userbinator wrote: post #20

Earlier quoted context omitted.

It's also much easier to decode x86 instructions when you look at them in octal instead of the hexadecimal that most tables use, since both the main opcode map and ModRM/SIB are organised in a 2-3-3 layout: http://reocities.com/SiliconValley/heights/7052/opcode.txt The 8080/8085/Z80 instruction sets also look much better in octal: http://www.z80.info/decoding.htm

This comment validates all the time I have "wasted" reading HN over the years. It does not suprise me that something so simple would be so well overlooked (or, at least, "forgotten"). I wonder if I ever would have figured this out from my own readings and experiments. Doubtful. Great tip!

I figured it out before/without exposure to that document, but I attribute it to the fact that I started teaching myself at a time when octal was more common amongst mini and micro-computers; most programmers these days barely know any number base other than decimal, and of those who do, binary and hexadecimal are likely far more familiar to them than octal. The official Intel/AMD manuals make no reference to octal either, using only binary and hex.

As an aside, ARM opcodes are (mostly) hex-structured with 4-bit fields, while MIPS, POWER, and SPARC are not amenable to any standard number base except binary (5- and 6-bit fields.)

Re: x86 Disassembly

#27

Post by calibraxis »

userbinator wrote: post #19
calibraxis wrote: post #11

Why does `push eax` perform "much faster" than the following? sub esp, 4 mov DWORD PTR SS:[esp], eax A brief skim of Intel's "Software Developer’s Manual" (particularly ch. 6 on stacks), didn't seem to find an answer. While hitting the ALU just for `sub` might be an extra step, doesn't hitting RAM make that a drop in the bucket? (`sub` may account for less than 1%?) Or is there some caching going on, so RAM may be up…

It's a lot smaller (1 byte vs 6), which means less space spent in the cache and decoder, reducing cache misses and decode bandwidth. The x86 also has a dedicated "stack engine" since the Pentium M (but not suprisingly, absent in NetBurst), which contains an adder and copy of the stack pointer to handle push/pop operations. This is faster than using the general-purpose ALUs and memory read/write ports, and also frees…

Thanks to you and awhitworth! Very interesting stuff, kept me reading. (And soon searching to understand some of the ideas. And thinking of Linus's puzzle about `call` being faster than a `push` before a jump. Seems to be one of those cases where higher-level abstractions can be optimized better than lower-level ones. I suppose because lower-level ones are too general-purpose, while higher-level ones are constrained.)

Re: x86 Disassembly

#28

Post by peterfirefly »

tptacek wrote: post #23
tptacek wrote: post #21

Earlier quoted context omitted.

I had no idea! This is very cool.

This is seriously exploding my brain. Thank you for posting it.

And that's really interesting (and puzzling).

You are clearly intelligent, well educated, etc. and blah blah blah.

Yet, you somehow missed that.

If you can explain why, it would probably be something we could all learn from. At the very least, it would be interesting.

Is it because you learned x86 before you learned octal and never really reexamined the encoding?

(The PDP-11 machine code also looks best in octal, btw.)

Re: x86 Disassembly

#29

Post by peterfirefly »

calibraxis wrote: post #11

Why does `push eax` perform "much faster" than the following? sub esp, 4 mov DWORD PTR SS:[esp], eax A brief skim of Intel's "Software Developer’s Manual" (particularly ch. 6 on stacks), didn't seem to find an answer. While hitting the ALU just for `sub` might be an extra step, doesn't hitting RAM make that a drop in the bucket? (`sub` may account for less than 1%?) Or is there some caching going on, so RAM may be up…

It's about dependency chains (and fewer bytes, easier decoding, and fewer µops). The OOO core can do more if it has more (but shorter) dependency chains to work with.

http://www.agner.org/optimize/microarchitecture.pdf

§7.7.

Post reply on HN