When assembly is still too high-level for Tomato

Current context (16 September 2026): the ISA now has 61 instructions plus NOP, occupying 62 burned rows. The 52-burn wording below is historical.

I’m expanding Tomato’s ISA beyond its current 52 burned opcodes, and one idea keeps becoming more important: the lower I go, the more of the machine I can actually see.

If I understand exactly what the hardware can do in one cycle, I can design algorithms around its natural operations instead of forcing the machine to imitate conventional instruction sets.

That matters on Tomato because the execution unit can evaluate operations of the form f(a, b, c) + g(a, b, c) + cin in one cycle.

A compiler—or a programmer writing ordinary assembly—may see an XOR3 combined with an unusual Boolean plane and break it into several familiar instructions. Tomato may already perform that entire expression directly.

That exposes an interesting problem: assembly itself can become an abstraction barrier. Mnemonics name what people already decided was useful. There is no natural name for every function the Dual-LUT can express—nor should there necessarily be. Restricting access to only the operations we know how to name leaves part of the machine unexplored.

So instead of asking what instructions Tomato should have, I want the more direct question: what is the most direct way to expose the computation the hardware is already capable of? If the doors and the keys already exist, why add another locked door between them? That is the direction as the ISA grows toward the rest of the 512-row ROM.

Authority: Tomato ISA · docs/isa/tomato.v1.csv.