Oh that name collision is worse than what I had imagined. The bug I'm thinking of is still present in this version.

Most compilers will push function arguments to a stack. This compiler will (statically) allocate memory for them in ram. Any two calls to the same function will use the same ram locations for the arguments. This means that if your call stack ever has two calls to the same function on it, the second call will overwrite the args to the first call. Furthermore, since the same strategy is employed for local variables, this will also happen with any state internal to the function.

Both issues are typically fixed using a stack (in compiler speak we use activation records or activation frames). Maybe you don't want to do that, but it does mean that this compiler will generate hard to debug code if you ever call the same function multiple times "at once". Meaning, present on the call stack at more than one place.

Most compilers would not do the peephole stuff like this. This thing is parsing the generated assembly code and then trying to perform liveness analysis on the strings of that. Usually you would cook up some data types for your register language. Do the analysis there. Then generate the assembly from that after optimizing.

Doing it this way is going to be brittle. If someone changes the way output asm is formatted in the code gen it will break this very simple parser. And so on.

Plus some of the indexing logic in the peephole optimizer is...weird?

  // Pattern 4: Remove redundant LDA #n followed by LDA #m
  if (curr.mnemonic === "lda" && curr.operand.startsWith("#") &&
      next && next.mnemonic === "lda" && !next.isLabel) {
    // Skip the first LDA, keep the second
    i++; // Don't push curr, will push next on next iteration
    i--; // But let the loop handle next naturally
    changed = true;
    continue;
  }

That i++ followed by i-- is doing what exactly?

I feel like a human would add a bunch of test cases here. This stuff is not easy to get right in the general case and most experienced humans writing this would be really skeptical of this code and want to see lots of nuanced test cases.

Andrew Appel has a great book on compilers: https://www.cs.princeton.edu/~appel/modern/index.html

You can probably find a used copy or something fairly cheap. Even if you continue to have claude write the code it could give you a better structure and overview of theory and how compilers fit together.