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

101–110 of 238 posts

Re: Learning to Read X86 Assembly Language

#101

Post by wolf550e »

pertymcpert wrote: post #93
makmanalp wrote: post #82

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…

It is a convention, it's called a procedure call standard. Compilers which conform to the PCS can call functions compiled by other compilers (that's how you can use libraries for example). If there's a bug in the compiler that results in non-PCS compliance, well that's a "fun" bug to track down.

I think "procedure call standard" is an ARM term. Linux on commodity hardware uses the "System V AMD64 ABI calling convention" (https://en.wikipedia.org/wiki/X86_calling_conventions#System...).

Re: Learning to Read X86 Assembly Language

#102

Post by andars »

spc476 wrote: post #66
adamnemecek wrote: post #52

Earlier quoted context omitted.

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).

Question I've been wondering about for a while: where does PCI fall into this? Do modern x86 PC systems still use in & out at all?

Re: Learning to Read X86 Assembly Language

#103

Post by makmanalp »

MichaelBurge wrote: post #92
makmanalp wrote: post #82

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…

> If you're compiling Rust code that calls into a C library, how does it know what registers to use?

Ah, interesting, I figured that the generated object files would just store some metadata on that basically.

Re: Learning to Read X86 Assembly Language

#104

Post by qwertyuiop924 »

emodendroket wrote: post #71
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.

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.

True enough. And this is the real reason x86 won.

Re: Learning to Read X86 Assembly Language

#105

Post by qwertyuiop924 »

wolfgke wrote: post #50
minimax wrote: 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…

Oh. Handy. I didn't know that.

Stupid outdated resources...

Re: Learning to Read X86 Assembly Language

#106

Post by flamedoge »

pcwalton wrote: post #74
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…

They should all have same binary encoding, which means they can all be decoded to any human readable format regardless...

Re: Learning to Read X86 Assembly Language

#107

Post by EvanAnderson »

spc476 wrote: post #67
EvanAnderson wrote: post #54

Earlier quoted context omitted.

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.

This sounds really interesting. I've never taken a look at the 6809 before. I happen to have a working Tandy CoCo I scored in a vintage computer haul. I'll definitely check out 6809 assembler.

Re: Learning to Read X86 Assembly Language

#108

Post by Ericson2314 »

spc476 wrote: post #66
adamnemecek wrote: post #52

Earlier quoted context omitted.

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).

Don't forget DMA is different from both of those too.

Re: Learning to Read X86 Assembly Language

#109

Post by detaro »

andars wrote: post #102
spc476 wrote: post #66

Earlier quoted context omitted.

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).

Question I've been wondering about for a while: where does PCI fall into this? Do modern x86 PC systems still use in & out at all?

PCI did for discovery, and could use it for device access (but often also memory-mapped). More info from the osdev wiki, which btw is a great place if you want to know about low-level initialization, the boot process etc.

http://wiki.osdev.org/PCI

Post reply on HN