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

Learning to Read X86 Assembly Language

patshaughnessy.net

Post reply on HN
Print view View original

71–80 of 238 posts

Re: Learning to Read X86 Assembly Language

#71

Post by emodendroket »

qwertyuiop924 wrote: post #42
wolfgke wrote: post #40

Earlier quoted context omitted.

> an absolutely ugly jumble of [...] religious backwards compatability, odd hacks, and various extensions Like POSIX, MS-Windows, X11, WinAPI, C++, HTML5, ... ;-)

Hey, I didn't say it was the only one. Although POSIX and HTML5 hold up a bit better than Win32 and C++, IMHO. Especially POSIX (it's not great, but it works pretty well). But I've heard X11 is absolutely miserable, so the windows folks don't have a monopoly on satanically evil APIs with religious backwards-compatability.

Probably because not breaking programs registers a lot higher on most people's priority list than making it easier to write -- especially when we're talking about assembly, which hardly anyone writes in the first place.

Re: Learning to Read X86 Assembly Language

#72

Post by DonaldFisk »

qwertyuiop924 wrote: post #4

x86 is the worst ISA. If you want to play with assembler without feeling a desire to stab yourself and end it all, I recommend ARM. Or go learn Z80, x86's weird, 8-bit cousin (it had a 16-bit version, but it sold poorly), which had a greater emphasis on backwards compatability (you can run code from the original 8080 on a Z80, unchanged), and is nicer to work with (because it wasn't extended in unticipated directions…

> x86 is the worst ISA.

I can only assume you've never had to program a Burroughs B90 in assembly language.

Re: Learning to Read X86 Assembly Language

#73

Post by userbinator »

ivanhoe wrote: post #49

To understand assembly it really helps to know at least something about how computers work on a low level. When I first tried learning it (long time ago, in a high school) I had no idea how computers really work on such a low level, how CPU's addressing registers and that kind of stuff, and while I managed to learn the syntax, even write some asm code, it was all really confusing to me. And only few years later on Un…

I always recommend this book for those who would like to know how computers really work:

https://www.amazon.com/Code-Language-Computer-Hardware-Softw...

Re: Learning to Read X86 Assembly Language

#74

Post by pcwalton »

userbinator wrote: post #70

What a train wreck! It’s hard to imagine a more confusing state of affairs. I'd say that's more attributed to someone many many years ago deciding they would not follow the official Intel syntax (for what reason I do not know), and somehow convincing the rest of the community to follow them. That's actually one of the things that could make for a very interesting article: how one processor family got two different an…

And Golang uses a separate syntax from Intel syntax and AT&T syntax, so now there are three incompatible syntaxes in common use. What a mess. :(

In Go's case it's because they wanted to have the syntax reflect the MachineInstr-like abstraction they have in place. I wouldn't be surprised if something similar was responsible for the AT&T syntax as well.

(In case it isn't clear, my preference is to do what LLVM does and to treat MachineInstr and machine code as distinct objects, and to use the vendor syntax for the human readable representation of the latter.)

Re: Learning to Read X86 Assembly Language

#75

Post by makmanalp »

adamnemecek wrote: post #2

Also Matt Godbolt's gcc explorer is the the bee's knees for understanding assembly https://godbolt.org/ I think that playing around with it for 2 hours will teach you more than most classes on the topic. It really drives home why interactivity is such a bit deal in education. You should also try writing a script for counting instructions in binaries. It's pretty illuminating. Here are some sample statistics https://w…

This is amazing. After a few minutes I learned so much already - try with an empty function that returns 0, then return an argument, then return an argument +1, argument^2, etc.

As an aside, I was looking at the header code generated by gcc to handle the initial function call. What's the convention on how we assign parameters to registers? I'm trying stuff out, and the first paramter always seems to be edi, then esi, eax. Except when I change the types, and it turns into xmm0 and the like. And the result returned is eax too, except when it's a float, then it's xmm0. How do things know where to look?

Re: Learning to Read X86 Assembly Language

#76

Post by userbinator »

qwertyuiop924 wrote: post #8
muterad_murilax wrote: post #7

Earlier quoted context omitted.

> There are only two common reasons to learn Z80 assembler, though: to program the Gameboy [...] and to program a TI calculator What about the myriad of other (mostly vintage) computer systems and video game consoles out there? ;) Sega Master System and Game Gear, for example.

They're not as common reasons. But yes, if you want to program your TRS-80 (but only the original: later ones were 6502), or your ZX* (How many of you lot know the ZX line? Spectrum? No?), or your Game Gear, or your Master System, or any of the various CP/M machines, you have to learn Z80.

How many of you lot know the ZX line? Spectrum? No?

The ZX Spectrum and its clones were very popular in the UK, Eastern Europe, and the former USSR.

Re: Learning to Read X86 Assembly Language

#77

Post by honkhonkpants »

JoeAltmaier wrote: post #17
honkhonkpants wrote: post #12

Earlier quoted context omitted.

I never felt more like stabbing myself than when trying to cipher out exactly which immediate values are possible on ARM, and which are not. X86 I happen to enjoy. It is not "the worst ISA" by any means. It has wonderful code density, which turns out the be very important. There's a reason that x86 won and continues to win.

When originally invented the x86 instruction set was efficient - the most-used instructions had shorter byte code sequences. But eventually some instructions got 'left behind' by the compilers. There are a whole host of single-byte instructions that are never, ever used by a compiler - the register exchange instructions for instance (xchg eax, ebx). Compilers just schedule destination registers carefully, never need…

Are you using the past tense because you are going to tell us about another contemporary ISA that has more code per byte? X86 _is_ compact and this continues to be relevant to performance today.

Re: Learning to Read X86 Assembly Language

#78

Post by jussij »

amw-zero wrote: post #58
theparanoid wrote: post #51

Earlier quoted context omitted.

It's helpful to realize x86 assembly is not what's executed by the machine; machine code is. One assembly instruction, e.g. ADDL, is translated to several different machine code instructions depending on the destination, source, and addressing mode.

Can you point to a source for this? All x86 assemblers that I know of map one assembly instruction to one machine instruction.

Here are the opcodes for the x86 ADD assembler instruction:

http://www.mathemainzel.info/files/x86asmref.html#add

The link shows nine ways to use the ADD instruction with each method resulting in a different opcode.

Re: Learning to Read X86 Assembly Language

#79

Post by adamnemecek »

makmanalp wrote: post #75
adamnemecek wrote: post #2

Also Matt Godbolt's gcc explorer is the the bee's knees for understanding assembly https://godbolt.org/ I think that playing around with it for 2 hours will teach you more than most classes on the topic. It really drives home why interactivity is such a bit deal in education. You should also try writing a script for counting instructions in binaries. It's pretty illuminating. Here are some sample statistics https://w…

This is amazing. After a few minutes I learned so much already - try with an empty function that returns 0, then return an argument, then return an argument +1, argument^2, etc. As an aside, I was looking at the header code generated by gcc to handle the initial function call. What's the convention on how we assign parameters to registers? I'm trying stuff out, and the first paramter always seems to be edi, then esi,…

> How do things know where to look?

The compiler generates code that uses the correct register. So the compiler picks a register into which it will put the result and then generates code after the calling location that gets the result from the correct register.

And yeah, there's quite a bit of surprises. E.g. I found out that gcc is smart enough to perform tail call optimizations https://godbolt.org/g/MZDmwP

Re: Learning to Read X86 Assembly Language

#80

Post by userbinator »

spc476 wrote: post #64
amw-zero wrote: post #58

Earlier quoted context omitted.

Can you point to a source for this? All x86 assemblers that I know of map one assembly instruction to one machine instruction.

I'm looking at the Microsoft Macro Assembler 5.1 Reference manual (it was nearby and easily accessible to me; yes it's old (from the very late 80s or early 90s) but it covers the 32 bit 80386, which is still valid. Anyway, it shows three different encodings for the ADD instruction. The first: 000000dw mod,reg,r/m This adds register to register, or memory to register (either direction, the d above) using either 8 or 1…

It seems to me that if w=1, then the s bit is extraneous and thus could be used to encode other instructions. I'm not sure if that is the case but it's common to use otherwise nonsensical instruction encoding to do something useful.

Opcode 82h is an alias for 80h --- it presumably sign-extends the immediate value into an internal temporary register, but the upper bits don't matter anyway since it's an 8-bit add. Some interesting discussion on that here, along with an example application:

http://computer-programming-forum.com/46-asm/143edbd28ae1a09...

Post reply on HN