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
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.