I was wrong...

I thought that having a carry flag would be enough to solve multi-precision arithmetic codes. It is not.

The conditional execution of instructions does not solve it either.

It is really necessary to have a ADC opcode that takes the carry bit as an input (and SBB as well).

And this is very worrying because the opcode map was frozen and now I need 2 more opcodes while all the opcode space is taken

It's not that multi-precision addition is expected to be very common but when it occurs, it gets ugly : it takes multiple instructions and registers, it loses orthogonality. I have covered a possible trick at https://hackaday.io/project/27280-ygrec8/log/199934-add-with-carry-the-macro but I don't like it.

ADC is easy to implement : it's just a AND gate between the output of the carry flag and the carry input of the adder. SBB is almost the same.

The real problem is that I thought it was not necessary. The opcode map has been frozen and now I need 2 more opcodes. I could dump CMPU and CMPS but their "no writeback" behaviour will increase register pressure or bloat code in common code sequences.

Any more complex reorganisation will break a lot of code as well as the electronic devices I have already built. It's not impossible but probably not worth it, as the opcode map has been thoroughly polished.

The last solution I see is ugly in the principle, but convenient : create a "prefix opcode" that enables the carry input.

• An I/O port address could be attributed to this function but it would read or destroy a register. Anyway : OUT 0 PC looks alluring.
• Using the case 3 from https://hackaday.io/project/27280-ygrec8/log/200314-undecided-overlay-options is possible but that would prevent register-defined overlays.
• Using coding space from INV is a last resort.

This also requires an update to the FSM

...