While I agree with the premise of the article, the code is completely unreadable to me. I took a look at the first snippet and just thought “Nah.”

I love low-level stuff and this still took me a little while to break down, so I’d like to share some notes on the author’s code snippet that might help someone else.

The function morse_decode is meant to be called iteratively by another routine, once per morse “character” c (dot, dash, or null) in a stream, while feeding its own output back into it as state. As long as the function returns a negative value, that value represents the next state of the machine, and the morse stream hasn’t yet been resolved into an output symbol. When the return value is positive, that represents the decoded letter, and the next call to morse_decode should use a state of 0. If the return value is 0, something has gone wrong with the decoding.

state is just a negated index into the array t, which is actually two arrays squeezed into one. The first 64 bytes are a binary heap of bytes in the format nnnnnnlr, each corresponding to one node in the morse code trie. l and r are single bits that represent the existence of a left or right child of the current node (i.e. reading a dot or dash in the current state leading to another valid state). nnnnnn is a 6-bit value that, when shifted appropriately and added to 63, becomes an index into the second part of the array, which is a list of UTF-8/ASCII codes for letters and numbers for the final output.

Also worth reading is how state machines can be encoded in the type system in some languages, for example the typestate pattern in Rust. By using the type system to encode state like this, you can prevent invalid operations on a state machine from even compiling.

State machines always make me think of the Disk II controller on the Apple II. It uses a state machine to implement reading and writing sectors to disk.

https://www.bigmessowires.com/2021/11/12/the-amazing-disk-ii-controller-card/