On 05/10/2012 02:51 PM, Peter Gavin wrote:
Hello,I'm working on the GNU simulator using cgen, which I have partway working at this point, and I've come across an interesting problem when comparing its results against or1ksim. When dumping a trace of the executed instructions using or1ksim, some instructions are not being disassembled properly in the trace, even though they appear to be simulated correctly. This does not happen for every instruction. A lot of them are disassembled just fine. For example, I put a simple program through or1ksim, and the trace dumps the following line: S 00000180: a8200001<invalid> The instruction is an l.ori instruction, from crt0.S in libgloss: /* Clear status register, set supervisor mode */ l.ori r1, r0, SPR_SR_SM SPR_SR_SM is equal to 0x1, so the encoding of this instruction should be: 101010 00001 00000 0000 0000 0000 0001 which matches the opcode 0xa8200001 in the output from or1ksim and in the binary. So basically, it looks like or1ksim is unable to disassemble some instructions for printing, but is able to simulate them just fine. Has anyone else seen this, or am I missing something?
Similiar problems have been seen before on 64-bit machines, Yann Vernier commited a couple of fixes for it, I can't remember if they propagated out to or1ksim though. Even if they did, it's not far-fetched to think that this could be related. Stefan _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
