On Wednesday 07 May 2008, Alan Stern wrote: > > ea0: 02 c0 40 41 brz,pn %g1, fa4 <usb_hcd_poll_rh_status+0x124> > > ea4: 01 00 00 00 nop Delay slot ... NOP gets executed before BRZ completes. > > ea8: c4 5e 20 d8 ldx [ %i0 + 0xd8 ], %g2 > > eac: a4 07 a7 e7 add %fp, 0x7e7, %l2 > > eb0: 90 10 00 18 mov %i0, %o0 > > eb4: c2 58 a0 78 ldx [ %g2 + 0x78 ], %g1 > > eb8: 9f c0 40 00 call %g1 > > ebc: 92 10 00 12 mov %l2, %o1 Delay slot ... "mov %l2, %o1" executed before CALLed %g1 routine starts to execute. > > ec0: a2 92 20 00 orcc %o0, 0, %l1 > > ec4: 04 40 00 1f ble,pn %icc, f40 <usb_hcd_poll_rh_status+0xc0> > > I'm going to need a little help with this, since I'm not acquainted > with SPARC assembler. > > The task dump showed that the address on the stack was > usb_hcd_poll_rh_status+0x40/0x180, which would be ec0 above. That > looks like it is the second instruction past the call to > hcd->driver->hub_status_data(). Is that right? And does one expect > the return address to be two past the call (call slot or some such > thing)? It's been a while since I used SPARC assembler too, but I think the answer is "yes". I don't think anyone would put delay slots into a new instruction set today, but that hindsight wasn't known when that instruction set was frozen. - Dave -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
