SIMDE-ULL / SIMDE

Educational computer simulator on a mission to "superscalate" the study of computer architecture fundamentals
https://simde.net
GNU General Public License v3.0
13 stars 11 forks source link

Investigate the correctness of cache faults handling #84

Open endes0 opened 7 months ago

endes0 commented 7 months ago

There are 2 mains issues:

https://github.com/etsiiull/SIMDE/blob/d577cd8cfc7bb244ac8c1ba0ab42797ea3391797/src/core/Common/Memory.ts#L49 As we have discussed, not allowing cache faults twice in a row is not necessary, this should fail at random.

https://github.com/etsiiull/SIMDE/blob/d577cd8cfc7bb244ac8c1ba0ab42797ea3391797/src/core/Superescalar/Superescalar.ts#L495 When we get a memory fault, we stall the FU, but that instructions is still executed. The correct behavior should be to stop that instruction execution the stall time. The same happens for the VLIW.

endes0 commented 6 months ago

I found another strange thing (possibly a bug): I accidentally set the NoCache mode to return always a fault (the got: false should have been got: true).

public getFaultyDatum(address: number): Datum | Error {
    const data = this.memory.getData(address);
    if (data instanceof Error) return data;

    return { value: data, got: false };
  }

I expected that this would cause an infinite execution of code that uses memory instructions, as the memory FU would always stall. Instead, the machine assumes that after a fault it always gets the datum, should be this the accepted behavior?

oxcabe commented 6 months ago

The machine assumes that after a fault it always gets the datum, should be this the accepted behavior?

Confirmed it is the accepted behavior. The fault increases the latency.