qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thiemo Seufer
Subject: Re: [Qemu-devel] [Bug] [Patch] MIPS code fails at branch instruction
Date: Sun, 25 Mar 2007 00:22:34 +0000
User-agent: Mutt/1.5.13 (2006-08-11)

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.

Can you check if this is the behaviour you see on an AR7?


Thiemo




reply via email to

[Prev in Thread] Current Thread [Next in Thread]