Hacker News Reader

Comment by Waterluvian | Hacker News Reader

This was a nice read, but I was hoping for something one step above this. When I was writing an emulator, I spent so much time looking at 8080(ish) code that I began to see constructs for bigger concepts. Like, “oh you’re setting up and running a loop over some subroutine X times.” “You’re checking if a certain math expression equals a certain value before continuing.” Etc.

I imagine an Assembly reader sees these things. I wonder if there’s a guide like this for them.

View on HN

An easy way to learn to see those patterns is through exploring compiler output:

https://godbolt.org/

Other than that, I like "Assembly Language Step By Step" by Jeff Duntemann, which is currently in its third edition and is Linux-only, as opposed to previous editions which were MS-DOS and Linux. He has example assembly code (Intel syntax for NASM, another reason I like his book) for download on his website:

http://www.duntemann.com/assembly.html

My only annoyance is that apparently, even the most recent edition from 2009 is still 32-bit only.

Anyway, beyond that, you'd be looking for information on using assembly language to perform some specific task, like writing vectorized numerical code.

Regarding the book, What would be the difference between 32bit and 64bit? Is it still relevant to read today?

Yes - it is one way to do it and it will work and be reasonably efficient. Everyone[1] who knows x86-64 asm today learned 32 bit first. You still have 32 bit instructions, and 16 bit, and 8 bit. The instructions will translate. You get more registers. You need to update the function and syscall calling conventions. There's no reason there can't be "learn x64 asm" books but there aren't many last I looked, but maybe someone can link us up to show how wrong I am?

https://wiki.osdev.org/Calling_Conventions

Richard Blum [2] after Dunteman.

[1] At a reasonable level of approximation.

[2] https://www.wiley.com/en-us/Professional+Assembly+Language-p...

I would doubt that, people haven't been running 32-bit x86 code for years at this point.

How exactly do you get away with not using the 32-bit subset of AMD64 ASM?

"32-bit x86 code" just means "code that does not use any of the AMD64 ISA." (And at this point, probably SSE2+ and a handful of other extensions.)

GP is correct: anyone that "knows" AMD64 assembly inherently must know 32-bit ASM because one must use the original x86 registers, instructions, etc. for the vast majority of tasks.

People are still constantly running what was formerly known as "32-bit x86 code" in their 64-bit applications.

I read “learned 32-bit first” as “learned on i386 machines”, not “learned what the 32-bit instructions do on 64-bit computers”. There’s a big difference between these two, because the way you write code for a machine that doesn’t do 64-bit is quite different, since you have many more registers, the calling convention is pretty different, etc.

From my very limited RE experience, one difference is calling convention: 32-bit passes a lot of stuffs on stack while 64-bit passes the first 8 (IIRC) through registers and the rest on stack. I could be wrong but this is one glaring difference. Another one of course is the registers them selves: EAX vs RAX for example.

I'll guess practical compiler books that goes down to assembly would also be helpful, especially those for those with inclination to language implementations. So far, I haven't read any though, and hope rui314's book comes out some day.

In my experience the most important parts of reading godbolt output are:

1. Data movements (mov)

2. Control flow (various jumps with corresponding tests, call and ret)

3. Calling convention. But you can often wing this and figure it out from context.

One thing I like for following the control flow is radare2 visual graph modes

> Intel syntax for NASM

Like the Good Lord intended.

I'm planning to write a future post on "common compiler generated code" to recognize those patterns. The intention of this post was to encourage folks who think asm is scary to give it a try because it's not as bad as they think. You really need to spend a bunch of time with godbolt or a debugger with a side-by-side source and asm view to really build an intuition for these things. I want to try to give folks the tools they need to start building that intuition, because you can read dozens of articles about asm and still have no idea what you're doing.

Maybe a decompiler can take you further:

https://boomerang.sourceforge.net/cando.php

https://www.backerstreet.com/decompiler/decompilers.htm

Reply on news.ycombinator.com