X86 assembly doesn’t have to be scary

Post by thechao » Mon, Jun 18, 2018, 9:03 PM UTC

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

Post by draw_down » Mon, Jun 18, 2018, 9:11 PM UTC

Post by MaxBarraclough » Mon, Jun 18, 2018, 9:22 PM UTC

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.

Post by e12e » Mon, Jun 18, 2018, 9:47 PM UTC

pjc50 wrote: post #44

nsxwolf wrote: post #42

Earlier quoted context omitted.

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.

  #include 

  char str[] = "Hello, World!\n";

  int main() {
    write(1, str, sizeof(str)-1);
    return 0;
  }

  .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_startproc
  	push	rbp
  	.cfi_def_cfa_offset 16
  	.cfi_offset 6, -16
  	mov	rbp, rsp
  	.cfi_def_cfa_register 6
  	mov	edx, 14
  	lea	rsi, str[rip]
  	mov	edi, 1
  	call	write@PLT
  	mov	eax, 0
  	pop	rbp
  	.cfi_def_cfa 7, 8
  	ret
  	.cfi_endproc
  .LFE0:
  	.size	main, .-main
  	.ident	"GCC: (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0"
  	.section	.note.GNU-stack,"",@progbits

Post by eterps » Mon, Jun 18, 2018, 9:52 PM UTC

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