Even more complicated, SHARC DSPs are 2-delayed, the pipeline fetch poitner is 2 instructions ahead than the one currently executing, that way the loop behaviour is a real bitch, because the loop condition is checked 2 instructions before the end of the loop (the registers are fetched 2 insts ahead) so if you change the register involved in the loop condition in the last instruction of the loop, it will take another loop to exit, weird, eh?. Fortunately I haven't seen any model2 game using that, so that part of the emulation is silently ignored in my current emulator :). Still all branches have to be 2 inst delayed, and the register dependencies between them caused me some problems.


> > The use of the term "delayed" is kind of a misnomer, at least when compared to
> > delayed branches.
>
> Not really, any changes to the program counter are delayed for one instruction.
>
> > My guess is that Tekken2's
> > use truely is a bug where a register was inadvertantly used in the first cycle
>
> I believe it was a missing nop in the jr ra of the called function, so it was
> executing the first instruction of the next function ( IIRC it was a mfc2 ). The
> instruction at ra then uses the register & needs it to be the old value, the
> pipeline should stall but it doesn't. In theory you should count the stalled
> cycles, but then you should also count the cache misses too. AFAIK the real
> r3000 doesn't have a stalling circuit, but the derivative the PSX uses does.
>
> I don't think the pipelines can be advanced when a cache misses or you'd end up
> with pretty random behaviour with regards to whether instructions in the delay
> slot would be executed or not.
>
> smf
>