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

81–90 of 238 posts

Re: Learning to Read X86 Assembly Language

#81

Post by adamnemecek »

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…

> how one processor family got two different and incompatible Asm syntaxes

Do you know the reason for this?

Re: Learning to Read X86 Assembly Language

#82

Post by makmanalp »

adamnemecek wrote: post #79
makmanalp wrote: post #75

Earlier quoted context omitted.

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

OK, so it's not a magical convention - it works it out bottom-up. First decide on registers for each parameter when you generate the code for the function, then based on that generate specific code for the instances where you call that function. Cool, thank you.

Also that example, heh. I tried to go back gcc versions to see if there was a case where it didn't do TCO - nope. Also, I like how returning 0 is "xor eax, eax".

Re: Learning to Read X86 Assembly Language

#83

Post by Merad »

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,…

This is determined by the calling convention [0]. If you're interacting with code that you didn't write, you need to know the calling convention that they use in order to set up arguments correctly.

0: https://en.wikipedia.org/wiki/X86_calling_conventions

Re: Learning to Read X86 Assembly Language

#84

Post by Jach »

tcrews wrote: post #61
qwertyuiop924 wrote: post #42

Earlier quoted context omitted.

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.

It helps to have actual real life experience under your belt when making such claims. You seem to be parroting what countless rants have already repeated without much content.

The GP didn't have much content either, merely listing off other obsessively backwards compatible things. Your reply might be suitable in a formal debate setting (as would "fallacy!" claims be suitable when challenging faulty deductive logic) but this isn't a debate, it's a conversation. The source of one's claims doesn't matter, you only know they're probably not from experience because the Parent was kind enough to share their age. The claims are used to drive the conversation and establish a shared context for further conversation (or at least ranting about the shape of our industry), not to debate.

Also reading the hard-won experience of others is much more efficient than trying to get it yourself. Books are wonderful. With enough books you can advance beyond the authors without having to tread the same paths, you parrot their findings as a base for your own. Or another case, you can at least be aware of common pitfalls your senior coworkers are constantly falling into because of an aversion to reading. Why do you know the pitfall is there? You're just parroting back what a book said. That doesn't make it untrue, or not useful to know, or not useful to share with other people, or even not useful to bring up to show there's a shared context.

Re: Learning to Read X86 Assembly Language

#85

Post by qwertyuiop924 »

int_hdlr wrote: post #59
qwertyuiop924 wrote: post #26

Earlier quoted context omitted.

I haven't jumped into the kernel yet. But I'm only 15. I still have time.

This is not a piss contest.

Never said it was.

Actually, it was more along the lines of that being a thing I should do at some point.

Re: Learning to Read X86 Assembly Language

#87

Post by qwertyuiop924 »

tcrews wrote: post #61
qwertyuiop924 wrote: post #42

Earlier quoted context omitted.

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.

It helps to have actual real life experience under your belt when making such claims. You seem to be parroting what countless rants have already repeated without much content.

That stung.

But fair enough.

Maybe I do need to do more research. Maybe I need to try new things.

I like to think I don't senselessly parrot, but that doesn't mean that I'm right.

Re: Learning to Read X86 Assembly Language

#88

Post by amw-zero »

jussij wrote: post #78
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.

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.

There's a bit of a miscommunication going on. What I meant was, when you write an assembly instruction, that maps to one machine instruction.

I.e., because of things like addressing modes, different invocations of an ADD instruction can map to different machine instructions. But one ADD invocation will always map to one machine instruction.

The parent comment sounded to me like one assembly instruction could map to several machine instructions, like one line of C is equivalent to several lines of assembly. Just wanted to clarify that that isn't the case.

Re: Learning to Read X86 Assembly Language

#89

Post by spc476 »

Grom_PE wrote: post #68

As AT&T syntax is still being used, at this point I'm willing to believe it's to purposely make x86 assembly hard and unpleasant to read and write. Perhaps so people will want to stay away from it, and in a way, to reduce the amount of code that is tied to the x86 platform. It spreads the thinking x86 assembly is terrible and ugly. Intel syntax is much cleaner, in particular, Intel Ideal (as opposed to MASM), and spe…

As I recall, the "dword ptr" stuff was only necessary if the instruction was otherwise ambiguous. Using EAX means you are using a 32-bit destination. But something like:

    move fs:[ebp-10],5
is ambiguous. Is that an 8-bit constant? 16 bits? 32-bits?

Re: Learning to Read X86 Assembly Language

#90

Post by qwertyuiop924 »

gtirloni wrote: post #63
qwertyuiop924 wrote: post #28

Earlier quoted context omitted.

The simple stuff's alright, but if you want to do anything performant, it gets hairy pretty fast, as you wade through almost 40 years of expansions and ugly hacks.

Could you elaborate in which situation you faced this issue?

Trying to learn it, at least beyond the basics.

Maybe I'm crazy, and I'm definitely inexperienced. So maybe take my opinion with a grain of salt?

But yes, so far as I've seen, trying to understand x86 in its present state is a painful experience.

Post reply on HN