> If I print the parameters at label `sigill' in emulate_load_store_insn(), I
> 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
> 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: email@example.com Pager: firstname.lastname@example.org
1225 Charleston Road Voice: (650)567-5025 FAX: (650)567-5225
Mountain View, CA 94043 Mobile: (650)868-6870 Admin: (650)567-5085