Close

Carry on

A project log for YGREC8

A byte-wide stripped-down version of the YGREC16 architecture

yann-guidon-ygdesYann Guidon / YGDES 03/29/2023 at 04:230 Comments

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.

This also requires an update to the FSM

...

Discussions