Live data from Hacker News

Learning to Read X86 Assembly Language

patshaughnessy.net

141–150 of 238 posts

Re: Learning to Read X86 Assembly Language

#141
post #50
post #48

Earlier quoted context omitted.

It also didn't have memory segmentation, otherwise known as The Worst Thing. The examples in the post are clearly x86-64 running in 64 bit mode. I.e. it's running in flat model... there is no segmentation to worry about.

The segment registers fs and gs still exist in x86-64 and are used. Under Windows gs (under x86-32 fs) points to the Thread Information Block (TIB): > https://en.wikipedia.org/wiki/Win32_Thread_Information_Block Under Linux gs is used for thread-local storage (TLS). But "as a typical programmer" indeed you only have to worry about the internal details of this if you are an OS developer, otherwise you can simply use t…

Google's Native Client uses segmentation to enforce sandboxing.

http://static.googleusercontent.com/media/research.google.co...

Re: Learning to Read X86 Assembly Language

#142
post #135

Earlier quoted context omitted.

I wouldn't be surprised if the reason was that people at Bell labs were mimicking some older syntax.

I remember reading a long time ago about the syntaxes and the author said that it is because AT&T assembled faster. Makes sense considering that the intel syntax requires some backtracking (or more of temporary data). (please don't upvote if you agree, i'm at 69 points :)

Apparently someone ignored your request, so I fixed it for you.

Re: Learning to Read X86 Assembly Language

#143

Earlier quoted context omitted.

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

I read it as one assembly instruction can map to one of several machine instructions.

That is also true --- for example, "mov reg, reg" is a special case of "mov reg, r/m" or "mov r/m, reg" with the r/m specifying a register, so basically two separate sequences of bytes which perform the same operation. This has been exploited by copy-protection and steganography, going back to the A86 shareware assembler which was the first use of this technique that I can remember, to more recent developments:

https://www.cs.columbia.edu/~angelos/Papers/hydan.pdf

http://stackoverflow.com/questions/17973103/why-does-the-sol...

(Almost wish that last link was cut off one letter earlier...)

Re: Learning to Read X86 Assembly Language

#144

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?

Familiarity with the VAX I'd say. Although that doesn't explain the % in front of registers. Maybe that came from SPARC? Looks like they tried to unify various asm syntaxes.

Re: Learning to Read X86 Assembly Language

#145

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…

You still need an overview of the instructions and registers. Knowing where the operator and operand of the instruction is also helpful. (i always mix up intel and at&t notations)

Re: Learning to Read X86 Assembly Language

#146

Earlier quoted context omitted.

>It also didn't have memory segmentation The Z80 only has a 16-bit address space. My favorite CISC architecture is the 68000 series.

Yes. But you could install an MMU. The 68k (and it's 8-bit semi-cousin, the 6809) were very nice. However, unlike the Z80, the 6502, and x86, they're no longer being made, and are increasingly rare.

The 68k is still being made in the form of the 680x0-compatible line from NXP. http://www.nxp.com/products/microcontrollers-and-processors/...

They're in the "legacy" line and labelled "not recommended for new design" but I think that's just design opinion and doesn't imply it's no longer made.

I'm sure this video has done the HN rounds before. It's a slow but fascinating watch. "Motorola 68000 Oral History Panel" from original Motorola team members. https://www.youtube.com/watch?v=UaHtGf4aRLs

Re: Learning to Read X86 Assembly Language

#147

Earlier quoted context omitted.

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

Suppose you're right and the registers are arbitrary. Then how would foreign function calls work? If you're compiling Rust code that calls into a C library, how does it know what registers to use? So the choice of registers cannot be arbitrary, unless the compiler knows the function is only used within an object file. The registers are predetermined by a convention unless you use the 'static' keyword to signal that t…

That is the role of operating system ABI, which definines the calling conventions between the programming languages on the OS.

Re: Learning to Read X86 Assembly Language

#148

I thought this sentence was curious: "To write code that runs directly on your microprocessor you need to know how memory segmentation works" Although you can't completely ignore segments, in practice at least on Linux the only segments in use are user code/data and kernel code/data segments. Does anyone know why the author might suggest that understanding segmentation is necessary to write Assembly code?

Probably because you need to deal with the MMU. You can't just write raw assembly and expect it to work (ignoring the MMU), but the kernel takes care of that for you.

Re: Learning to Read X86 Assembly Language

#149

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…

A few years ago I decided to convert the Asm syntax of my toy compiler from Intel to AT&T, because I wanted to rely only on as, not forcing people to install another Assembler.

Since as had some issues with the Intel syntax I was using, I decided to not use its support for the syntax and convert it to AT&T.

Never again, it is just plain ugly.

Compared with DOS/Windows Macro Assemblers (TASM, MASM, NASM, ...), AT&T ones are just plain pre-historic.

Re: Learning to Read X86 Assembly Language

#150

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…

This. The AT&T syntax for x86 thing is a huge mistake. All the official docs are Intel syntax. Intel syntax is easier to read and write. Half the gotchas in this article are problems that don't exist in Intel syntax, like the instruction suffixes. The instruction suffixes get even weirder when you get to the sign extending instructions. I wrote an article about this here: http://blog.reverberate.org/2009/07/giving-up…

Additionally Intel syntax Macro Assemblers offer higher level constructs providing almost C like experience while using machine opcodes.
Post reply on HN