Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

X86 assembly doesn’t have to be scary

blog.benjojo.co.uk

Post reply on HN
Print view View original

71–80 of 129 posts

Re: X86 assembly doesn’t have to be scary

#71

Post by Veedrac »

krylon wrote: post #10

I think to many programmers assembly is the "GOTO" of programming languanges: From the day you start learning to program, you are told that all this fancy high-level-language stuff is there so you do not have to deal with assembly. So most people never go there. I did go there, briefly, about ten years ago. It was wicked fun. But all in all, I may have written maybe 20 or 30 instructions of assembly in total. I did t…

You got 20-30 instructions in, drew, and decided it was impossible to do better? That's calling it quits a bit early.

Re: X86 assembly doesn’t have to be scary

#72

Post by brandmeyer »

thechao wrote: post #51
blattimwind wrote: post #47

Earlier quoted context omitted.

> I wonder if the history of x86 is holding us back in a big way. It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly describes. But when you compare high-end cores, you always see the same picture, regardless of ISA. Large surface area (~1/3 of the core) used for insn fetch/decode/schedule; they look all the same,…

Even 15 decoders are a pinprick on the core’s area—at least when I saw die area for LRB. Fetch & schedule we’re a bit larger. Most of the core area was register files & floating-vector logic.

In fairness, Larrabee was originally an in-order design.

Re: X86 assembly doesn’t have to be scary

#74

Post by cesarb »

e12e wrote: post #57
pjc50 wrote: post #44

Earlier quoted context omitted.

That's referring to the label msg.len, which is a value computed at compile time in the 'data' section at the bottom. msg: db "Hello, world!", 10 .len: equ $ - msg 'msg' is a label, which will be assigned to an address at compile time. 'db' short for 'declare bytes' puts some bytes at that address. '.len' is then defined as the current output address ($) minus the start of the string.

In addition to all these excellent comments, it can also be instructive to go "backwards" from C, here on Linux: cat hello.c #include char str[] = "Hello, World!\n"; int main() { write(1, str, sizeof(str)-1); return 0; } cat hello.s .file "hello.c" .intel_syntax noprefix .globl str .data .align 8 .type str, @object .size str, 15 str: .string "Hello, World!\n" .text .globl main .type main, @function main: .LFB0: .cfi_…

"lea" is a fun instruction.

Going piece by piece: on x86, each register has several sizes. For instance, rax is a 64-bit register, with its lower 32-bit half being eax, its lower 16-bit half being ax, and its lower 8-bit half being al (for historical reasons). So when a register name starts with "r", it's the 64-bit variant. Therefore, "rip" is the 64-bit address of the next instruction.

The instruction "mov rsi, str[rip]" would get the 64-bit address of the next instruction, add to it a fixed offset (which the assembler and linker compute for you, as the exact offset you need to get to the data at the "str" label), load 64 bits from that address, and put the result in the "rsi" register. And that's not even the most complex addressing mode; you can get a register, add to it another register multiplied by 2, 4, or 8, add to it a constant, and use it as the memory address to load, store, or even modify in-place.

The "lea" instruction (load effective address) is a way to get directly at the power of that complex address calculation logic for your own uses. Instead of using the computed memory address to get at the memory, it's the memory address that's put in the register. Therefore, where "mov rsi, str[rip]" would read from memory, "lea rsi, str[rip]" would put in rsi the memory address the "mov" would have read from.

This also allows for a few tricks. For instance, you can use "lea" to multiply a number by five, without using the multiplier: just use a register and the same register scaled by 4 (and you can also add a constant to the result, still in a single complex instruction).

Re: X86 assembly doesn’t have to be scary

#75

Post by userbinator »

tvmalsv wrote: post #20

When I was about 14 I was enthralled with programming my new Commodore 64, first in BASIC, then 6510 assembly. I had the opportunity to accompany my mother to a one-day class on programming. Being just an intro on the subject, I was well ahead of what they would be discussing, but thought it would interesting to talk to some adults that were also into programming. I was talking to a couple of guys about what I had be…

It's funny how you can just adapt and work with whatever is available, and that becomes your norm. Especially when you don't even realize there are other options out there.

Another example of this, also quite relevant to the article, is the 64K address space of a 16-bit segment; to anyone who is used to HLLs, 64-bit address spaces, and gigabytes of RAM, it seems impossibly small. Even more so when you take a modern C++ compiler with all its default settings and produce a 72KB(!) "Hello World" binary.

One of the things you quickly realise when you work with Asm is that it's not impossibly small; everything is os just horribly bloated --- piles of abstractions upon abstractions, using gargantuan statically-linked library functions of which a tiny fraction of the bytes is actually executed, etc. Try writing a nontrivial utility in 16-bit realmode Asm, where a "Hello world" is around a dozen bytes, and you'll find that 64KB is actually quite a lot already. In particular, look at the 256b and below DOS categories in the demoscene:

http://www.pouet.net/prodlist.php?type%5B%5D=32b&type%5B%5D=...

Those effects were accomplished using fewer bytes of machine instructions than the text of this post, which is already over 1KB. Really makes you think.

Re: X86 assembly doesn’t have to be scary

#77

Post by bogomipz »

blattimwind wrote: post #47
ChrisSD wrote: post #11

I wonder if the history of x86 is holding us back in a big way. It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly describes. And surely the whole spectre issue could be lessened if we could be less reliant on CPUs having to guess what to keep in cache, which code paths are most likely, etc?

> I wonder if the history of x86 is holding us back in a big way. It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly describes. But when you compare high-end cores, you always see the same picture, regardless of ISA. Large surface area (~1/3 of the core) used for insn fetch/decode/schedule; they look all the same,…

>"What we do know is outside some niches (like DSPs, where VLIW reigns king)"

Interesting, why is VLIW is so predominant in DPS chips?

Re: X86 assembly doesn’t have to be scary

#78

Post by ksk »

inferiorhuman wrote: post #70
ksk wrote: post #34

Earlier quoted context omitted.

>It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly describes. Well, the fact that we were able to abstract it out into an ISA, and still make progress would indicate that it isn't holding us back! >And surely the whole spectre issue could be lessened if we could be less reliant on CPUs having to guess what to kee…

> Well, the fact that we were able to abstract it out into an ISA, and still make progress would indicate that it isn't holding us back! Just because something works doesn't mean it works well. Imagine if x86-64 ditched the variety of non-32/64-bit modes. Would x86 be able to better compete with ARM in power consumption?

> Imagine if x86-64 ditched the variety of non-32/64-bit modes. Would x86 be able to better compete with ARM in power consumption?

In what way? Do you mean instruction decoding? There is very little separation between x86 and ARM on that. x86 is optimized like crazy for the common instructions.

https://en.wikipedia.org/wiki/CPU_cache#Micro-operation_(%CE...

Re: X86 assembly doesn’t have to be scary

#79

Post by BeeOnRope »

inferiorhuman wrote: post #70
ksk wrote: post #34

Earlier quoted context omitted.

>It started out being close to the metal but now it's an abstraction that can mislead you if you think processors are literally working the way x86 assembly describes. Well, the fact that we were able to abstract it out into an ISA, and still make progress would indicate that it isn't holding us back! >And surely the whole spectre issue could be lessened if we could be less reliant on CPUs having to guess what to kee…

> Well, the fact that we were able to abstract it out into an ISA, and still make progress would indicate that it isn't holding us back! Just because something works doesn't mean it works well. Imagine if x86-64 ditched the variety of non-32/64-bit modes. Would x86 be able to better compete with ARM in power consumption?

Not really, those use a microscopic amount of area on a modern die and shouldn't have much power impact at all when they aren't being used.

You could probably change the ISA in various ways to save power, or make other uarch or arch changes - but cutting out say the 16-bit modes isn't really one of them.

Re: X86 assembly doesn’t have to be scary

#80

Post by tvmalsv »

gruez wrote: post #24
tvmalsv wrote: post #20

When I was about 14 I was enthralled with programming my new Commodore 64, first in BASIC, then 6510 assembly. I had the opportunity to accompany my mother to a one-day class on programming. Being just an intro on the subject, I was well ahead of what they would be discussing, but thought it would interesting to talk to some adults that were also into programming. I was talking to a couple of guys about what I had be…

>"How can you possibly write anything with only three registers?!" AFAIK you can even go down to 1 register, which is how stack machines work. You might even say it’s 0 registers because it’s not something you can directly access.

I was going to say "Man, that'd be terrible to work with!" And immediately realized I'm no different than those 8088 guys in that class :) You work with what you have.
Post reply on HN