j (invalid.delete@this.example.net) on November 3, 2019 11:30 pm wrote:
>
> Sorry, poor wording on my part. I didn't mean anything related to hypervisors, virtual
> machines or the like. What I meant was whatever microarchitectural tricks which are
> needed to avoid bottle-necking performance on writing/reading the flags register.
>
> AFAIK one common approach is to split up the flags register into several "virtual" registers (hence
> my use of the term "virtualizing") that can be handled separately. I don't know if they go all the way
> to having one such virtual register for each bit in the flags register, or if they are grouped.
>
> Another might be to duplicate the flags, so that each normal register would have an associated flags register
> containing the flags for the latest instruction that wrote to that register, and then instructions that
> depend on the flag register such as jumps would somehow need to pick up a dependency on the correct flags
> register. Or maybe this is pointless if you just rename the flags as any normal register?

Maybe you are the person to ask. Why not implement a duplicate set of narrow registers to hold all ALU flag results? Some ISAs (Power?) implement multiple addressable flag registers but instead, extend this to a full set in parallel with the register file removing the need to separately address them on stores.

Not only would store addressing be free since it is just the register address, but reads from the parallel register file holding the flags do not compete with regular register file reads. For instance if the zero flag was saved even though it can be computed at any time, then a test for zero does not require register file access.