Hi Ali, Thank you for your reply. Is there any method to set final_val = Dest2<<32 + Dest1 ?
Thanks, Meng On Jun 26, 2013, at 3:51 PM, Ali Saidi <[email protected]> wrote: > > > Hi Meng, > > There are some more exotic instructions that we don't > print the correct dissambly for or get the data a bit wrong. The way the > data works is pretty much the last register that is written to becomes > the final_value of the instruction and that is what is printed. > > You > can see some beautiful (j/k) generated code that looks something like > this: > > uint32_t final_val = Dest; > > ((dest == PCReg) ? setNextPC(xc, > Dest) : > xc->setIntRegOperand(this, 0, Dest)) > ; > if (traceData) { > traceData->setData(final_val); } > } > { > uint32_t final_val = Dest2; > > > ((dest2 == PCReg) ? setNextPC(xc, Dest2) : > xc->setIntRegOperand(this, > 1, Dest2)) > ; > if (traceData) { traceData->setData(final_val); } > > In > the particular case I picked the data printed is always what was in > Dest2. > > Ali > > On 26.06.2013 13:37, Meng Wang wrote: > >> Hi all, >> "ldrd > Rm, Rn, <addr>" is an ARM instruction for loading two continuous words > at <addr> into two registers Rm, Rn. It can execute correctly but its > dumping information seems wrong. I wrote an simple assembly code to > test: >> >> .section .text, "ax" >> global _start >> _start: >> mov r0, > #0xff // r0 = 0xff >> mov r1, #0x11 // r1 = 0x11 >> str r0, [sp], #4 // > store 0x11 to <addr>, sp +=4 >> str r1, [sp], #4 // store 0x11 to > <addr+4>, sp +=4 >> ldrD r2, r3, [sp, #-8] // r2 = value in <addr>, r3 = > value in <addr+4> >> mov r4, r2 // r4 = r2 >> mov r5, r3 // r5 = r3 >> # > following is exiting. >> exit: >> mov r0, #0 >> mov r7, #1 >> svc 0 >> > .end >> >> Run it on SE mode and dump it with Exec flag: >> >> 1. 0x8054 : > mov r0, #255 : IntAlu : D=0x00000000000000ff >> 2. 0x8058 : mov r1, #17 : > IntAlu : D=0x0000000000000011 >> 3. 0x805c.0 : str r0, [sp] #4 : MemWrite > : D=0x00000000000000ff A=0xbeffff20 >> 4. 0x805c.1 : addi_uop sp, sp, #4 > : IntAlu : D=0x00000000beffff24 >> 5. 0x8060.0 : str r1, [sp] #4 : > MemWrite : D=0x0000000000000011 A=0xbeffff24 >> 6. 0x8060.1 : addi_uop > sp, sp, #4 : IntAlu : D=0x00000000beffff28 >> 7. 0x8064 : ldrd r2, r3, > [sp, #-8] : MemRead : D=0x0000000000000011 A=0xbeffff20 >> 8. 0x8068 : > mov r4, r2 : IntAlu : D=0x00000000000000ff >> 9. 0x806c : mov r5, r3 : > IntAlu : D=0x0000000000000011 >> 10. 0x8070 : mov r0, #0 : IntAlu : > D=0x0000000000000000 >> 11. 0x8074 : mov r7, #1 : IntAlu : > D=0x0000000000000001 >> 12. 0x8078 : svc : IntAlu : >> >> In line 7 of > dumped trace, should trace value "D=0x0000000000000011" be > "D=0x00000011000000ff"? (Assuming the configuration is little endian). > >> >> Thanks, >> Meng >> _______________________________________________ >> > gem5-dev mailing list >> [email protected] >> > http://m5sim.org/mailman/listinfo/gem5-dev [1] > > > > Links: > ------ > [1] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
