Hacker News Reader

Comment by cryne | Hacker News Reader

I tried to replicate this on my 64 bit machine, so

  nasm -f elf64 tiny.s && ld -s tiny.o

  ; tiny.asm
  BITS 64
  GLOBAL _start
  SECTION .text
  _start:
                mov     eax, 1
                mov     ebx, 42  
                int     0x80

and this lands me at 4320 bytes! Why is there such a stark difference?

View on HN

> Why is there such a stark difference?

Your linker must align the .text section to the page size (often 4096 bytes). If you open the binary with a hex editor you'll see lots of null padding.

If that's a hard lower limit, then it really invites a different sort of code golf / demo to see how much functionality you can stuff into a 4K(ish) binary

> If that's a hard lower limit

I think it's some sort of optimization (retrieving one page of memory should be easier than two, right?). With GNU ld I can do

    ld -s -Ttext=0x4000b0 tiny.o

and shave off 3920 bytes on my system.

The real hard limit is 73 bytes [0], to actually run any code in the executable without segfaulting right away. You can cram about 3 simple syscalls into that limit (e.g., my BGGP4 submission [1], which copies the executable to another file), including the final exit() or exit_group() if you want your program to terminate cleanly. Strings are very costly: I couldn't get a Hello World below 77 bytes.

[0] https://tmpout.sh/3/22.html

[1] https://github.com/binarygolf/BGGP/pull/3/files, assembly at https://gist.github.com/LegionMammal978/347c939def56dcba449c...

Reply on news.ycombinator.com