Difference between revisions of "Case Studies"

From SizeCoding
Jump to: navigation, search
m (tiny compiler is really a compiler)
m (display Řrřola's name properly)
Line 5: Line 5:
 
:[[m8trix 8b]]: An "Enter The Matrix" screen display in only 8 bytes
 
:[[m8trix 8b]]: An "Enter The Matrix" screen display in only 8 bytes
  
:[[4is256]]: rrrola's Tetris is a full tetris clone with scoring
+
:[[4is256]]: Řrřola's Tetris is a full tetris clone with scoring
  
 
:[[paint16b]]: Hellmood's paint program in 16 bytes (really)
 
:[[paint16b]]: Hellmood's paint program in 16 bytes (really)

Revision as of 17:31, 14 August 2016

Sometimes it can be helpful to examine a tinyprog in detail, seeing what choices were made and why:

MELT.COM: We take a cute program from the 1980s and see how far we can crunch it down
m8trix 8b: An "Enter The Matrix" screen display in only 8 bytes
4is256: Řrřola's Tetris is a full tetris clone with scoring
paint16b: Hellmood's paint program in 16 bytes (really)

External Case Studies

Brainfuck is a very tiny language, having only 8 commands and an instruction pointer. Several interpreters have been made; Gynvael archived many different versions along with their source code, the smallest of which was 125 bytes. qkumba took that as inspiration and created his own brainfuck compiler in 100 bytes (104 for one that is fully compliant). (Note: The term "compiler" is used mistakenly a lot in these descriptions; the majority of brainfuck programs are actually interpreters that load brainfuck programs and execute native code token by token. This one is an exception in that it really does compile the code entirely into native instructions first).

Disassembly of Farbrausch's "fr-016: bytes"

A disassembly of the 64-byte version of Klappquadrat

Maze generation in 10 bytes