Show HN: Game of Life in 32 bytes of assembler (opens in new tab)

(source included in the link, writeup will follow) To my knowledge, the first implementation ever in 32 bytes. This builds upon the 65 bytes version of Vladislav Kaipetsky, Tenie Remmel and Mark Andreas from 1998.

Edit: The writeup is now available : http://www.sizecoding.org/wiki/Game_of_Life_32b

Capture : https://www.youtube.com/watch?v=EgqiLf19og4

This comment is more than 32 bytes

While it absolutely doesn't hold a candle to 32 bytes :) I'm reminded of the 1691-byte IOCCC entry from 1991 which drew the Game of Life on the root X server window without using Xlib.

I'm completely naive about Life implementations, and I've always been curious if the approach used by this entry is especially interesting; it's certainly a fascinating read (https://www.ioccc.org/1991/davidguy.hint):

The algorithm used to compute the next generation is based on the observation that a cell's state in the next generation is a boolean function of its current state, and the states of its 8 neighbors (ie, a boolean function from 9 bits to 1 bit). This function can be computed by a boolean circuit. In addition, intermediate values computed by the circuit can be shared between neighboring cells, reducing the number of gates per cell required.

These ideas have been used before, to compute the next generation through a series of bit blits. Instead of doing this, we map values in the circuit to bits in registers, so that the next generation can be computed efficiently within registers, minimizing memory accesses.

As a result, the computation of the next generation is performed with about 1.6 instructions per life cell, consisting of .125 memory accesses, .17 shifts, and 1.3 logic operations. The net result is that the time to transfer the bits to the X server, and for the X server to draw them on the screen, dominates the time to compute the next generation.

I'm not sure what I did last time I tried to get this working and failed; it works great on Debian 10 with GCC 8.3 etc:

$ wget https://www.ioccc.org/1991/davidguy.fix.c

$ gcc -o davidguy davidguy.fix.c -m32

$ xhost +

$ ./davidguy

If your X server is not :0, change the last character of the ".slo.-W00,tmhw.W/" string to be one less in ASCII to the display number (ie 0 -> /, 1 -> 0, 2 -> 1, etc).

The main reason I added this comment was out of curiosity about the technical competence/interestingness of the implementation.

I'm blown away. I can't even begin to think how to encode GoL in such a small program.

Jaw dropping.

twt86 link below...

http://twt86.co?c=xSQgswcIBKfALQWRAkFeAkD8AoCcAEt18ooE%2BdLY...

Not the same class because it's a high-level language, but this J version is worth mentioning at 26 bytes, and is beautifully readable if you're familiar with J:

    (]=3+4=*)[:+/(>,{;~i:1)&|.

Disclaimer: I am not the original author of this snippet.

Try it online:

https://tio.run/##y/qvpKeepmBrpaCuoKNgoGAFxLp6Cs5BPm7/NWJtjb...

The terminals connected to my university's Burroughs 6700 mainframe in 1981 had a 8080 processor in them and there was an escape sequence that allowed you to type some hex code into the input buffer and run it. So of course I did Life. It was probably more than 32 bytes but not much larger as I was able to memorize the hex. It wasn't quite right since it used the updated values for half of the neighbors due to the lack of double buffering.

This is truly incredible.

Modbyte tuning is amazing, but I'm still a bit confused how you jump back into the modbytes.

32 bytes = how many jigawatts