We have a lot of special purpose instructions/opcodes which are fun to play with but which wouldn't exist in a real processor, for example:

• MEMCPY
  • Could be implemented via PEEK/POKE and a loop
• SYSTEM
  • Can't be implemented by hand, but isn't so terribly useful
  • At least in part because the results are output to the console and not stored in a register.

We're also missing the ability to carry out some operations, either in a simple fashion, or at all:

• We can't convert a string to uppercase easily
  • Though we could iterate over some memory and cmp >= 'a' && <= 'z'
  • We can't iterate over the characters in a string stored in a register though, or modify them in-place.
• We can't input string from the user into a register/RAM.
• We can't draw to the console.
  • Meaning we can't write "tetris" or other simple games.

If this were a real CPU we'd call into fixed addresses into ROM to get support for things, or we'd have an interrupt function. For example we could define the INT 0xNN instruction. Then using that we could provide facilities

• INT 0x00
  • Read a string from the user, store in register #0.
• INT 0x01
  • Output a single character, as stored in #0
• INT 0x02
  • Return the length of the string stored in #0
• INT 0x03
  • Draw the character stored in #0 at coordinates #1,#2
• ..

In short we could add higher-level useful utilities in a way that didn't require the addition of more single-purpose instructions. I don't have a strong view of what things are missing, because I've never tried to write "complex" programs for this CPU, but if we're all about the learning then it should be possible to do so!

We should have two opcodes for pushing all registers and popping all registers - this would make writing routines to be called useful.

Move the stack & register implementations into their own files and add tests.

Instead of using HCL.

Also add staticcheck tests.

The original c intepreter was fuzzed with AFL, which resulted in a couple of bug-fixes.

It would be worth fuzzing this application with a go-based fuzzer. I'm not yet familiar with any, but no doubt they exist.

I'm just curious, that is,
why is the stack implemented as fisrt-in-first-out style? is there any special consideration?

Since our registers hold integers in the range 0x0000 0xFFFF they should wrap when they reach the limits. This example:

    store #1,0
    dec #1 

Should result in register #1 containing 0xFFFF.

This is supposed to be a 16-bit system, as our address-space is capped at 64k, and our registers hold (integer) values in the range 0x0000-0xffff only.

However our registers overflow:

 store #0, 0xFEFE
 store #1, 0xFEFE
 add #3, #0, #1
 print_int #3

The result of this program is 0x1FDFC. Instead we should be % 0xFFFF. We handled the case of inc and dec wrapping correctly in #2 but we need to cap registers more generally.

A simple solution would be to update SetInt to add & 0xFFFF which would limit the value. However a better solution might be to test for this overflow in all the math-operations and set a (new) [C]arry flag.

To do this we'd need to:

• Add the new flag.
• Set it on all suitable math-operations.
• Add JMP_C and JMP_NC operations.

I could go either way, since this machine is posted for learning it could make sense to either:

• Simplify because it isn't real.
• Add the opcodes because they demonstrate something useful.

Feedback welcome...