The PPK Tiny Programming Results

mikemacd writes "As mentioned before the folks over at properkernel.com ran a programming challenge. The results are in. Hopefuly they will post code too."

Comments

My 155 byte entry

[mikemacd]

For anyone who cares, this was my entry which compiles to 155 bytes. Compile with (nasm -f bin -o tiny tiny.asm), and make executable (chmod o+x tiny), execute (./tiny)

I use al,bl,cl,dl instead of eax,ebx,ecx,edx because they are only one byte wide instead of 4 bytes saving 3 whole bytes per use !!!

; Created by Michael MacDonald (mikemacd@sympatico.ca)
;
; Thanks to: http://www.muppetlabs.com/~breadbox/software/tiny/ teensy.html for tips on shrinking the code.

BITS 32
org 0x00001000
ehdr: ; Elf32_Ehdr
db 0x7F, "ELF", 1, 1, 1 ; e_ident
times 9 db 0
dw 2 ; e_type
dw 3 ; e_machine
dd 1 ; e_version
dd _start ; e_entry
dd phdr - $$ ; e_phoff
dd 0 ; e_shoff
dd 0 ; e_flags
dw ehdrsize ; e_ehsize
dw phdrsize ; e_phentsize
dw 1 ; e_phnum
dw 0 ; e_shentsize
dw 0 ; e_shnum
dw 0 ; e_shstrndx
ehdrsize equ $ - ehdr
phdr: ; Elf32_Phdr
dd 1 ; p_type
dd 0 ; p_offset
dd $$ ; p_vaddr
dd $$ ; p_paddr
dd filesize ; p_filesz
dd filesize ; p_memsz
dd 5 ; p_flags
dd 0x1000 ; p_align
phdrsize equ $ - phdr
section data
msg db "The deep gray mouse runs after the holy yellow cheese.", 0x0A
len equ $-msg
_start:
mov dl, len ;message length
mov cx, msg ;message to write
mov bl, 1 ;file descriptor (stdout)
mov al, 0x4 ;system call number (sys_write)
int 0x80 ;system call
mov al,1 ;system call number (sys_exit)
int 0x80 ;system call
filesize equ $ - $$

Code and bins for the entries...

[kernelistic]

I guess this is where they stashed the code for the entries.

Not a winner?

[fava]

It looks like the winning entry actually does not output the required string. If you look at the winning entries code it is actually outputting the string:
'The deep ' 0x0 0x1 0x0 ' gray mouse runs after the holy yellow cheese.' 0xA
Where the 0x0 0x1 0x0 are required fields in the ELF header that splits the message into two halves. The output might appear to be correct when displayed on a terminal but if you redirect it to a file you will see the extra bytes.

Modifying the code to not output the extra bytes would add 9 bytes to the program and it would larger than the next smallest binary, assuming that the 104 byte entry didn't use the same trick.

Yay! I got on the high scores!

[andfarm]

I'm in the list, and pretty close to the optimum value, too! (169 bytes for me. The lowest was 101, and they sort of cheated.)

The source (yes, nasm input == source) to my entry is available here.