0 Members and 5 Guests are viewing this topic.
Quote from: calc84maniac on December 08, 2009, 09:22:08 amBy the way, is the emulator's speed accurate? I mean, I added a delay loop of "loop subs r8,r8,#1 \ bne loop" when r8 contained 400,000, and that was for each of 60 frames. That loop should be 4 cycles per iteration, right? That adds up to delays of more than 90MHz, which doesn't add up.It's not accurate. Right now, it just assumes all instructions are one cycle, or 1/90 microseconds. If your computer is not fast, it can lag, however. A tight loop like that is very likely to lag; I would recommend adding a few dozen repetitions of a simple instruction like "mov r0,r0" which nspire_emu can execute very fast.
By the way, is the emulator's speed accurate? I mean, I added a delay loop of "loop subs r8,r8,#1 \ bne loop" when r8 contained 400,000, and that was for each of 60 frames. That loop should be 4 cycles per iteration, right? That adds up to delays of more than 90MHz, which doesn't add up.
Edit: Would more accurate cycle counting slow down the emulation significantly? (Aside from the fact that instructions would take longer)
Quote from: calc84maniac on December 08, 2009, 03:09:54 pmEdit: Would more accurate cycle counting slow down the emulation significantly? (Aside from the fact that instructions would take longer)That depends on what version of ARM the Nspire uses. The newer versions have longer pipelines, and the longer a CPU's pipeline is the more complicated it gets to predict how long something will take. Let's just hope it's not an ARM11 model.
so does this mean it will run slower on the actual calc then?
Quote from: miotatsu on December 08, 2009, 08:25:18 pmso does this mean it will run slower on the actual calc then? Definitely slower than it has been running. No way to tell yet whether it will still run games fullspeed though.
Edit: Found the cycle counts here.
Maybe you can do something different with the register accesses on the couple of instructions afterward - basically on the load from memory you could do "interlockcount = cyclecount + 2" and upon register accesses, "if reg == loadedreg and interlockcount > cyclecount: cyclecount = interlockcount"
Quote from: calc84maniac on December 09, 2009, 02:46:59 pmMaybe you can do something different with the register accesses on the couple of instructions afterward - basically on the load from memory you could do "interlockcount = cyclecount + 2" and upon register accesses, "if reg == loadedreg and interlockcount > cyclecount: cyclecount = interlockcount"If I made the translator actually emit code to do that I think it would slow emulation way down, with several real instructions added per emulated instruction. It needs to precompute cycle counts as much as possible.
And keep in mind that this solution only applies to the ldrb/ldrh opcodes, not ldr. In the ldr case, you can simply add an extra cycle to the following instruction if it accesses the loaded register.