The LRU and pseudo-LRU methods have a different behaviour, depending on the hit or miss event. The influence of read or write is not yet taken into account.

Considering the ideal, true LRU : the tag bits are only updated if the last way is different than the MRU field. my LRU behaves this way too but with fewer fields to compare, hence fewer chances of update.

The whole cache cycle is a 4-step dance:

1. take a portion of the address bits to address one set of the cache, and read it all, latch it in a large buffer.
2. compare the (4) address tag fields with the upper part of the desired address, encode the result down to 3 bits : 2 "way" bits (2× OR2) and 1 "hit" bit (OR4).
3. LRU magic : the just read tag bits are mixed with the "way" bits to create new LRU tag bits.
4. the eventual new data is sent along with an eventual new address to the selected way, and the LRU tag bits are updated for the whole set (when applicable).

Note : here I don't consider the (unlikely) case of partial access. The whole line is used, 16 or 32 bytes at once.

The link between 3 and 4 has some implicit assumptions that must be clarified. It all depends if there was a hit or miss, and read or write.

......

to be continued