Live data from Hacker News

X86 assembly doesn’t have to be scary

blog.benjojo.co.uk

41–50 of 129 posts

Re: X86 assembly doesn’t have to be scary

#41
post #37

It's hard to find a tutorial that really tells you what is going on. You have to start with whatever operating system you're on, then figure out what the heck you're reading. What is x86 and what is some reserved word peculiar to the assembler you're using? Here's macOS Hello, world code I see floating around a lot, and I can't make heads or tails of it: global start section .text start: push dword msg.len push dword…

Some tips for learning:

1. It's much easier to study the disassembly of object files than executables. Or better yet, use -S to ask the compiler to emit assembler.

2. Don't use hello world as your first program. Those involve either library calls or system calls. Strings too, and strings are not so straightforward in any systems programming language. Start with single functions (not called main) that take two arguments and add them/subtract them/multiply them.

3. Try learning x86-64 first. It's easier to learn because you don't have to know about the stack to understand and write simple arithmetic functions, if they take no more than six arguments.

4. It usually helps to pass -Os to the compiler to have it generate more compact code. You won't see lots of superfluous code to load/store things to the stack (for debugability) but you also won't see autovectorized code.

Re: X86 assembly doesn’t have to be scary

#42
post #40
post #37

It's hard to find a tutorial that really tells you what is going on. You have to start with whatever operating system you're on, then figure out what the heck you're reading. What is x86 and what is some reserved word peculiar to the assembler you're using? Here's macOS Hello, world code I see floating around a lot, and I can't make heads or tails of it: global start section .text start: push dword msg.len push dword…

Basically everything left-aligned is for the assembler, and the indented material is the mnemonics for the x86 set. The assembler breaks down as: push dword msg.len push dword msg push dword 1 Place a pointer to the message, its length, and 1 on the stack. Each of these decrements esp by 4. mov eax, 4 We'll be doing syscall 4 in a sec sub esp, 4 Reserve 4 bytes for the return int 0x80 Do the syscall! See https://open…

But then there's that "msg.len", which I assume is some sort of assembler shortcut for getting the length of an array and not part of the x86.

Re: X86 assembly doesn’t have to be scary

#43
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…

I also started as a programmer on a C64. BASIC didn‘t get you very far, so assembly it was. The machine code monitor, all the three letter mnemonics and ??? when it couldn‘t disassemble are fond memories. When I switched to the PC I had great hopes but outright hated it after a short while. All this restrictions on the registers were confusing. The segment modell even more. And good graphics required programming the…

The segment model was the thing I really hated. It didn't help that the DOS program that I sold for a number of years sort of ran out of in-memory space for data and I ended up doing a bunch of whacky things with segments rather than rewrite it from scratch. Which I eventually started to do but, at that point, it didn't make sense to put the work in.

Re: X86 assembly doesn’t have to be scary

#44
post #42
post #40

Earlier quoted context omitted.

Basically everything left-aligned is for the assembler, and the indented material is the mnemonics for the x86 set. The assembler breaks down as: push dword msg.len push dword msg push dword 1 Place a pointer to the message, its length, and 1 on the stack. Each of these decrements esp by 4. mov eax, 4 We'll be doing syscall 4 in a sec sub esp, 4 Reserve 4 bytes for the return int 0x80 Do the syscall! See https://open…

But then there's that "msg.len", which I assume is some sort of assembler shortcut for getting the length of an array and not part of the x86.

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.

Re: X86 assembly doesn’t have to be scary

#45
post #24

Earlier quoted context omitted.

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

There are many simple microcontroller architectures with only one register, usually called A (accumulator) or W (work register). You just need to constantly load memory to and from the register, nothing weird in that. Sometimes they will call their memory locations registers, in which case they have lots of registers - the terminology gets quite unclear when everything is on the same chip anyways. A true stack machin…

RPN calculators are simple stack machines.

Re: X86 assembly doesn’t have to be scary

#46
post #38
post #27

Earlier quoted context omitted.

I agree with you to an extent: The IBM PC was not a very elegant design, and other computers certainly had less complexity to them. But there is a point I want to make which defends this choice somewhat: Newbies like me are more frustrated by thinking there's no path from introductory material to something useful or realistic. Something that's more immediately friendly would be a simplified virtual machine with no or…

Well, I had in mind something more useful and realistic, not less; namely teaching assembly in normal Linux environment. Sure, there are all sorts of complexities there too, but in general I feel like they are also more worthwhile.

> Well, I had in mind something more useful and realistic, not less; namely teaching assembly in normal Linux environment.

This might sound odd, but as someone who's done some assembly programming under Linux, it usually isn't different enough from C to be worth the effort. Even if you eschew libc, the kernel APIs are still fairly high-level and, more to the point, there are no new concepts relative to C: You have pointers and pointer arithmetic, you have fixed-size buffers, you have ints and doubles, and the rest is just syntax.

The exception is doing something like a really tight high-performance kernel using SIMD opcodes, which necessarily involves learning a lot about the specific SIMD hardware and data organization to optimize cache use and other details C can't express.

Re: X86 assembly doesn’t have to be scary

#47
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, whether it's POWERn or the latest Sandy-Bridge/Haswell rehash... people claim that other ISAs would be a lot easier/faster/more efficient to decode, but that doesn't seem to be true in practice. It seems to me that any difference that might be there gets dwarfed by the sheer complexity of OoOE and speculative execution.

What we do know is outside some niches (like DSPs, where VLIW reigns king) static techniques essentially do not work for application code, because it's impossible to predict statically.

Re: X86 assembly doesn’t have to be scary

#49
post #19
post #6

Loved the article. Then one can follow up with some MS-DOS classics. https://www.amazon.com/Peter-Nortons-Assembly-Language-Book/... https://www.amazon.com/Advanced-S-DOS-Programming-Microsoft-... https://www.amazon.com/Peter-Norton-Programmers-Bible-progra... https://www.amazon.de/PC-Intern-Programming-Encyclopedia-Dev...

I see your Norton and raise you an Abrash: https://www.amazon.com/Zen-Assembly-Language-Knowledge-Progr... https://www.amazon.com/Zen-Graphics-Programming-2nd-Applicat... https://www.amazon.com/Zen-Code-Optimization-Ultimate-Softwa... Zen of Asm is also online, I think a few of the other works, too. http://www.jagregory.com/abrash-zen-of-asm/

I'm sure I still have my paper copy someplace. I still remember that you did things differently on an 8086 than an 8088 for example because of the difference in the width of the external data bus. Cycle counting. I'm not sure I learned much that was practical from it but it was the ultimate in optimizing x86 assembler code.

As I recall, he was going to write a sequel but, by then, it would have been fairly pointless.

Re: X86 assembly doesn’t have to be scary

#50
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…

I also started as a programmer on a C64. BASIC didn‘t get you very far, so assembly it was. The machine code monitor, all the three letter mnemonics and ??? when it couldn‘t disassemble are fond memories. When I switched to the PC I had great hopes but outright hated it after a short while. All this restrictions on the registers were confusing. The segment modell even more. And good graphics required programming the…

Didn't the Amiga's graphics system also use bitplanes?
Post reply on HN