[Top] [All Lists]

Re: unaligned load in branch delay slot

To: Geert Uytterhoeven <>
Subject: Re: unaligned load in branch delay slot
From: "Mike Uhler" <>
Date: Mon, 13 Jan 2003 09:19:45 -0800
Cc: Linux/MIPS Development <>
In-reply-to: Your message of "Mon, 13 Jan 2003 17:13:17 +0100." <>
Original-recipient: rfc822;
> If I print the parameters at label `sigill' in emulate_load_store_insn(), I
> get:
>     pc 0x80346448 addr 0x83d9f81e ins 0x14600012
> And emulate_load_store_insn() gets confused because 0x14600012 is not a
> load/store. 0x14600012 is the branch instruction before the load, not the load
> after the branch instruction! Note that bit 31 of cause (CAUSEF_BD) is not 
> set.
> Some more investigations showed that the branch is indeed not taken.
> Apparently if an unaligned access happens right after a branch which is not
> taking, epc points to the branch instruction, and CAUSEF_BD is not set
> (technically speaking, this is not a branch delay, since the branch is not
> taken :-). Is this expected behavior? The CPU is a VR4120A core.
> As a workaround, I assume I can just test whether pc points to a branch
> instruction, and increment pc if that's the case?

Prior to the MIPS32/MIPS64 architecture definition, which requires that EPC
point at the branch and the Cause[BD] bit be set on any exception in the
branch delay slot, there were a few CPUs which interpreted the rules in the
manner that you describe.  I don't happen to have a VR4120A manual in front
of me, but the behavior you describe could easily be the case of this differnt



  Michael Uhler, VP, Systems, Architecture, and Software Products 
  MIPS Technologies, Inc.   Email:   Pager:
  1225 Charleston Road      Voice:  (650)567-5025   FAX:   (650)567-5225
  Mountain View, CA 94043   Mobile: (650)868-6870   Admin: (650)567-5085

<Prev in Thread] Current Thread [Next in Thread>