Add Load/Store Unit

programmerjake commented

2026-07-31 04:24:16 +00:00

Owner

This covers all the logic between the rename/execute/retire circuits and the d-cache, this includes the store queue, store-to-load forwarding, speculatively loading from the cache, managing dependencies between loads/stores, etc.

The d-cache just has to handle running loads/stores of sets of bytes in proper sequence, as well as a separate speculative load interface (which only returns data for cache hits). There's also space in the d-cache interface for reporting writes/flushes caused by i/o devices or other cpu cores, but actually handling those is left for another PR for libre-chip/grant-tracking#20.

It tests by making random sequences of up to 8 loads/stores and running them and randomly causing cancels (within the limits of what the load/store unit was told about if instructions are speculative) and then when all instructions have retired it verifies that the final memory state matches what's expected (which includes both cacheable memory's values as well as the exact sequence of I/O reads/writes). it runs that test sequence 40 times with different random seeds.

I added ExecuteToUnitInterface::other_units_cant_cause_cancels_before to the rename/execute/retire logic to tell units when the only thing that can cancel a µOp is the same unit it's in, this allows more efficient load/store pipelining because the load/store unit doesn't have to wait for a load/store to be fully non-speculative before running it since it can cause globally-visible side-effects which can't happen until the CPU knows it isn't mis-speculated.

I also added a flag for uncacheable load/stores to LoadStoreMOp.

Closes: libre-chip/grant-tracking#17
Closes: libre-chip/grant-tracking#18

This covers all the logic between the rename/execute/retire circuits and the d-cache, this includes the store queue, store-to-load forwarding, speculatively loading from the cache, managing dependencies between loads/stores, etc. The d-cache just has to handle running loads/stores of sets of bytes in proper sequence, as well as a separate speculative load interface (which only returns data for cache hits). There's also space in the d-cache interface for reporting writes/flushes caused by i/o devices or other cpu cores, but actually handling those is left for another PR for https://git.libre-chip.org/libre-chip/grant-tracking/issues/20. It tests by making random sequences of up to 8 loads/stores and running them and randomly causing cancels (within the limits of what the load/store unit was told about if instructions are speculative) and then when all instructions have retired it verifies that the final memory state matches what's expected (which includes both cacheable memory's values as well as the exact sequence of I/O reads/writes). it runs that test sequence 40 times with different random seeds. I added `ExecuteToUnitInterface::other_units_cant_cause_cancels_before` to the rename/execute/retire logic to tell units when the only thing that can cancel a µOp is the same unit it's in, this allows more efficient load/store pipelining because the load/store unit doesn't have to wait for a load/store to be fully non-speculative before running it since it can cause globally-visible side-effects which can't happen until the CPU knows it isn't mis-speculated. I also added a flag for uncacheable load/stores to `LoadStoreMOp`. Closes: https://git.libre-chip.org/libre-chip/grant-tracking/issues/17 Closes: https://git.libre-chip.org/libre-chip/grant-tracking/issues/18

programmerjake added 3 commits 2026-07-31 04:24:17 +00:00