The order of writing the GPRs

[zhaoxiahust]

Hi All,

In the pipeline, the A2I core writes the data into GPRs (general purpose registers) after the ex7 stage which is named as ex8 or rf1. My current understanding of A2I is that different instructions of one thread can actually write the data into the register file out-of-order.

For example, there are two instructions, i.e., "Load RegA, addr1"; and "Add RegB, RegC, RegD". If the load instruction misses in the L1 cache, it will be stored in the LMQ and waiting to access the L2 cache. In this case, if the add instruction keeps executing, it will write the data into GPR before the load instruction. If this is the case, the order of writing the register file for these two instructions, i.e.., load and add, is out of sequence. Is it the right understanding?

If I understand correctly, how can A2I guarantee the precise interrupt or exception? For example, one exception happens after the add instruction writing the GPRs.

Thanks!

[openpowerwtf]

It does appear to execute independent ops under a load miss, but I don't see much description. In D.5.2 Loads:

A similar situation applies to write-after-write hazards on load misses. While a load miss is outstanding, the thread cannot complete further writes to the same GPR.

RAW/WAW hazards are handled with combination of flush/stall, depending on cycle relationship with load miss.

This is allowable with some special handling. Once the load has passed translate/alignment/etc. checks, it won't generate a precise exception; it's like a long-latency move. So subsequent (independent) ops can finish up to the next synchronizing event (like certain ops or sync/async interrupts) , as defined by ISA. Then everything up to that point has to be allowed to complete, to maintain the appearance of 'sequential execution', before execution continues.

[zhaoxiahust]

Thanks for the help! I can understand that exception should be fun since writing registers only happen in EX8 or rf1. I am thinking about the interrupt, will it destroy something? For example, after the later add instruction writing the result into the GPR, an interrupt comes and the early load data still does not come back. How does A2I deal with this case?

[openpowerwtf]

Right, the exception logic has to handle all those interesting cases to ensure the ISA requirements are met. A 'hung load' would usually be treated as a checkstop case. Even if there weren't ops executed after the load, it would likely be an unrecoverable error and probably a data integrity problem, especially in a SMT/SMP environment. It looks like A2I does detect it in hardware, as a machine check exception (you can see in the ISA that system reset/machine check interrupts have special allowances related to sequential execution).

Data Asynchronous Machine Check Exception A data asynchronous machine check exception is caused when one of the following occurs: • A timeout, read error, or read interrupt request is signaled on the A2 core interface during a data read operation. • A timeout, write error, or write interrupt request is signaled on the A2 core interface during a data write operation. • A parity error is detected on an access to the data cache. XUCR[MDCP] is used to disable parity recovery