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

61–70 of 238 posts

Re: Learning to Read X86 Assembly Language

#61

Post by tcrews »

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.

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.

Re: Learning to Read X86 Assembly Language

#62

Post by anarazel »

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.

I suspect the instructions they are thinking about are cpu-level uops.

Re: Learning to Read X86 Assembly Language

#63

Post by gtirloni »

qwertyuiop924 wrote: post #28
SeanDav wrote: post #25

Earlier quoted context omitted.

In my day I wrote a fair amount of x86 assembly language. I found it fairly easy and straight forward. There are probably even less reasons to learn it these days but nothing gives you a better idea of how a computer works (arguably, besides microcode, but that is a different kettle of fish).

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?

Re: Learning to Read X86 Assembly Language

#64

Post by spc476 »

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.

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 16/32 bits (the w above [1]). The second form:

    100000sw mod,000,r/m
This adds an immediate value (8 or 16 bits, w again) to a register. The s bit is used to sign extend the data (s=1; otherwise, 0-extend it) if required [2]. The final form:

    0000010w data
This adds an immediate value to the accumulator register (EAX, AX, AL) [1]. That's three different encodings for the "same" instruction. The MOV instruction (and again, I'm only talking about the 80386 here) has 8 different encodings, depending upon registers used.

[1] If the current code segment is designated as a 16-bit segment, then the w means 16 bits, unless a size override byte (an opcode prefix byte) is present, in which case it means 32-bits. If the current code segment is designated as a 32-bit segment, then the w means 32 bits, again unless a size override byte is present, in which case it means 16-bits.

[2] 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.

Re: Learning to Read X86 Assembly Language

#65

Post by Gracana »

qwertyuiop924 wrote: post #38
busterarm wrote: post #36

Earlier quoted context omitted.

I'd recommend learning 68k instead. Or MIPS. But definitely Z80 over x86. x86 is pain.

I wish 68k, but it's out of production (as is the 6809, its equally awsome 8-bit cousin). MIPS and ARM are fun, though, AFAICT. As is 6502.

If you want something friendly and CISC-y and modern, check out the Renesas RX600 and friends. They have a nice instruction set and zero-wait-state RAM and ROM, so writing assembly by hand with predictable timing ought to be easy.

https://www.renesas.com/en-us/doc/products/mpumcu/doc/rx_fam...

Re: Learning to Read X86 Assembly Language

#66

Post by spc476 »

adamnemecek wrote: post #52
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…

Yeah stuff like dma isn't getting enough attention in a lot of treatments of the subjects. Also in/out instructions (did you ever consider how a CPU talks to a HDD)?

Two ways. The first is IO mapped IO, which is what the x86 supports with the IN and OUT instructions. All this really is is a MOV to a different "address" space (16 bits of addressing). The second is memory mapped IO, in which hardware is mapped to the addressing space of the CPU (Motorola 68K uses this format). A CPU that allows IO mapped IO can also do memory mapped IO (it's not precluded).

Re: Learning to Read X86 Assembly Language

#67

Post by spc476 »

EvanAnderson wrote: post #54
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…

I agree that the x86 ISA is pretty warty (though I have a strange fondness for it), but I'd recommend 6502 rather than Z80. There are a lot of fun retro-computer platforms that are 6502-based. Thinking of the zero-page functioning as a register-bank is really fun, too.

For 8-bits I'd recommend the 6809. Two 8-bit accumulators that can be used as a 16-bit accumulator, 4 16-bit index registers (that can largely be interchanged, except for S which is also the stack register) and you can generate pure relocatable code. And the zero-page isn't restricted to address $0000.

Re: Learning to Read X86 Assembly Language

#68

Post by Grom_PE »

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 specifically, FASM (flat assembler). FASM makes it as clean as possible and turns writing assembly into a joy.

Compare:

    movl %fs:-10(%ebp), %eax       ; AT&T
    mov eax, dword ptr fs:[ebp-10] ; MASM
    mov eax, [fs:ebp-10]           ; FASM

Re: Learning to Read X86 Assembly Language

#69

Post by spc476 »

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…

Been done (somewhat). The PERQ (https://en.wikipedia.org/wiki/PERQ) had a writable instruction set. And I think Transmeta was trying to do something similar with translating x86 code to an internal format for execution.

Re: Learning to Read X86 Assembly Language

#70

Post by userbinator »

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 and incompatible Asm syntaxes. The fact that the mnemonics and syntax don't correspond to those found in the manufacturer's datasheets and manuals just increases the barrier to understanding. As far as I know, the same didn't happen to ARM, MIPS, SPARC, and the others. Especially when the sense of the comparisons/conditional jumps is reversed, and some of the more advanced addressing modes look less-than-obvious, it's hard to imagine why anyone would adopt such a syntax:

http://x86asm.net/articles/what-i-dislike-about-gas/

Note that the GNU tools have option to use Intel syntax too, so you can avoid some of the confusion (in the DOS/Windows and embedded world at least until recently, Intel syntax is overwhelmingly the norm.)

Post reply on HN