6 ms·

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:

by cryne 2y ago

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?

oguz-ismail 2y ago
> 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.
- yjftsjthsd-h 2y ago
  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
  - oguz-ismail 2y ago
    > 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.
  - LegionMammal978 2y ago
    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 https://tmpout.sh/3/22.html [1] https://github.com/binarygolf/BGGP/pull/3/files https://github.com/binarygolf/BGGP/pull/3/files, assembly at https://gist.github.com/LegionMammal978/347c939def56dcba449cb54dd9ee22f4 https://gist.github.com/LegionMammal978/347c939def56dcba449c...