On Mon, 10 Jul 2006 22:53:42 -0400, Daniel Jacobowitz <dan@xxxxxxxxxx> wrote: > > I noticed that checking for CP0_CAUSE.BD is unneeded, since we are > > checking the instruction code anyway and "rdhwr" does not have a delay > > slot. I removed the checking on the "take 2" patch I just sent. > > Isn't BD "this instruction is in a delay slot", not "this instruction > has a delay slot"? It affects where we go when we return. Well, the BD means "the exception occurred on a delay slot of this (which EPC points) instruction". If rdhwr was in a delay slot, EPC points the preceding jump/branch instruction. This fast path is reading a instruction at the EPC (regardless BD), so it must not be "rdhwr" and fall back to slow path. > BTW, if the fast emulation can't handle rdhwr in a delay slot, please > report a bug on GCC asking it not to put rdhwr in delay slots by > default. It's probably worthwhile. If rdhwr was on a delay slot, the slow emulation will be more slower. So I think rdhwr should not be put on delay slot anyway regardless fast emulation. I asked on GCC bugzilla a few days ago but can not got feedback yet. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28126 --- Atsushi Nemoto
