Custom Query (93 matches)
Results (10 - 12 of 93)
Ticket | Resolution | Summary | Owner | Reporter |
---|---|---|---|---|
#35 | fixed | Bug in the Sparc V8 component (LDA instruction) | ||
Description |
While trying to run a sample code on the sparc processor, an error arised : line 80, the test if(ins.format3a.i == 0) { \ m_exception = true; \ m_exception_cause = TP_ILLEGAL_INSTRUCTION; is actually the contrary : if(ins.format3a.i == 1) { \ m_exception = true; \ m_exception_cause = TP_ILLEGAL_INSTRUCTION; cf. the sparc V8 reference manual, p. 160 (163), test on code line 9. |
|||
#36 | invalid | [MIPS32] sync does not flush read operation as it is supposed to | ||
Description |
When sync is called on Mips32, only pending write operation are flushed, and not the pending read operation, as they are supposed to. |
|||
#37 | wontfix | Mips32 strange behavior | ||
Description |
Hello, I have encoutered some problems with the mips32 iss, I have the following behavior on a miss instruction meanwhile an irq is raised : t-0 : The mips32 issues an address to the cache wrapper which miss in the tag. The cache wrapper sets the iss_t::InstructionResponse.valid to false (stall the processor). t-1 : The cache wrapper send a read request to the memory and wait for the response. Meanwhile, the mips32 receive at each cycle a negative response for InstructionResponse.valid. t-2 : The processor receives an irq, and CHANGES the output adress (next_pc). t-3 The cache receives the response from the memory and updates the TAG with the NEW address (which is incorrect), because it did not expect that the processor could change the output address beign stalled. My question is the following : Is a correct behavior for the mips32 to take into account an irq (or other event) meanwhile it is stall ? I know that on other processors a stall signal freezes the state of the processor, so it will mantain the same output address until it "hits" in the cache. Thank you for your highlights to this question. |