That...is awesome. Will take some time to wrap my head around.

Here's a simpler approach that also supports either ST or IO: https://github.com/qpliu/dcpu16/blob/master/DCPU16.hs

A9 52 20 D2 FF A9 49 20 D2 FF A9 50 20 D2 FF

For the curious, it's:

LDA #$52 JSR $FFD2 LDA #$49 JSR $FFD2 LDA #$50 JSR $FFD2

It outputs "RIP" on a Commodore 64.

To my eternal shame, I had to look up the kernel vector at $FFD2. (it outputs a character to the current device, usually the screen, on the C64). At least I can redeem myself partially by having remembered the opcodes...

SET PC, [SP++]

SET PC, [--SP]

SET PC, [location with I/O]

> SET PC, [SP++] > SET PC, [--SP]

Good call, detecting (PC, SP) fixed point then, although using the stack to jump onto itself is wicked. I don't want to go and solve the halting problem either.

> SET PC, [location with I/O]

Qualifies as outside force. I'm not sure I want to write/run a program that JMP to an @ provided by I/O, this reads like an SQL injection.

It seems to me the extra cycle is used to read the first word of the next instruction, since it needs to know how long the next instruction is to skip it.

I would have gone for something big and expensive, like, say, the lunar module. Is anyone making a new lunar module or a hydrogen dirigible these days?

What's the rationale for piping sort into wc?

That looks like it was a sample line that wasn't particularly useful, but if you do:

cat file.txt | sort | uniq | wc -l ## notice uniq

it gives you the count of unique lines. If you omit the sort in that instance it will fold duplicates together a/b/a is three lines, not two.

Instead of "sort | uniq" you could just use "sort -u"