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
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.
Comments
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
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...
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
and shave off 3920 bytes on my system.