Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction

[Aurelien Jarno <aurelien@aurel32.net>]

Thiemo Seufer a écrit :
> Stefan Weil wrote:
>> Hi,
>>
>> here is the patch which adds a "4KEcR1" CPU (a 4KEc, processor revision 2.2,
>> with MIPS32 Release 1 (!) instruction set is the heart of the AR7 SoC).
>>
>> See also include/asm-mips/cpu.h in the Linux kernel sources:
>> ./include/asm-mips/cpu.h:#define PRID_IMP_4KEC          0x8400
>> ./include/asm-mips/cpu.h:#define PRID_IMP_4KECR2        0x9000
> 
> This was the bit which prompted to to ask The People Who Know[TM].
> Indeed the early 4KEc were MIPS32R1 only. About the branch-in-delay-slot
> I got the following information:
> 
> Very simple pipelines with branch delay slots tend to behave like this
> (when both branches are taken):
> 
>  - Execute the first branch, that is, calculate the target of the
>    branch. This has no effect until it ran far enough through the
>    pipeline. Increment PC.
>  - Execute the second branch. This changes the branch target value
>    again. Increment PC.
>  - Execute the second branch's delay slot instruction. Increment PC.
>  - Now the PC is overridden by the first branch's target. A single
>    instruction from that place is executed.
>  - The PC is overridden again by the second branch's target. Normal
>    execution resumes from there.
> 
> Apparently the SPARC architecture _requires_ this behaviour for all
> CPUs.

Yep I confirm that, it is clearly explained starting at the page 54 of
the SPARC v8 manual. To avoid this behaviour it is possible to cancel
the delay slot instruction by having a=1.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net