Condition codes are notoriously bad. Log 21. Conditional execution and instructions doesn't even scratch the whole subject but my latest "trick" is worth a whole log.

During private discussions with @Drass about the memory granularity, I realised that unaligned access was probably handled in the YASEP with the wrong perspective. When doing an insertion or extraction of a 16-bits word in a 32-bits architecture, the instruction would set the Carry flag to indicate when the extracted sub-word overlaps the natural memory word boundary. This way the program can detect if/when more code must be executed to fetch the remaining byte from the next word.

It's a little harmless kludge but it works in theory. Unfortunately this is not scalable. This wouldn't work with #F-CPU  for example.

My CPUs typically have the following condition codes or flags :

• Carry (for add/sub/comparison)
• Zero (the result, or the register, is cleared)
• Sign (the MSBit of the register is the sign, useful for shifts and giggles)
• Parity (odd/even is the LSBit of the register, quite useful as well)

Today's unkludging is an extension of the parity bit : more bits are created that provide information about alignment  before the fact, unlike the IE method. It also simplifies the logic for carry generation (I don't know why I chose to modify this bit in particular, and not the Parity bit)

In summary:

• For your 16-bits CPU, you just need the P flag.
• For 32 bits, you also need an extended parity that is a OR of the 2 LSBits, so you would have flags P1 and P2.
• For 64 bits : same again, you would have P1, P2 and P3, that you can check before any access to a Data register.

This is "good" because:

• Usually, to perform the same function, you have to issue a AND instruction with a bitmask (1, 3 or 7 for example) which adds some latency to the program and requires a temporary register to hold the result.
• The results of the ORing for the LSB can be stored in "shadow" bits that can be placed closer to the branch decision logic.
• You can test the pointer before using it, instead of after the fact
• The instruction decoder could eventually trap before emitting the unaligned instruction.

The less nice part is the increased coding space required in the instructions, to hold 1 or 2 more codes.