Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!cs.utexas.edu!romp!auschs!awdprime!moody!moody From: moody@moody..austin.ibm.com Newsgroups: comp.sys.ibm.pc.rt Subject: Re: APC loop mode bug? Summary: Bug summary Message-ID: <1931@awdprime.UUCP> Date: 28 Mar 90 17:58:32 GMT References: <1990Mar28.144727.15576@athena.mit.edu> Sender: news@awdprime.UUCP Reply-To: moody@awdprime.austin.ibm.com.UUCP () Distribution: na Organization: IBM AWD, Austin, TX Lines: 50 In article <1990Mar28.144727.15576@athena.mit.edu> jfc@athena.mit.edu (John F Carr) writes: > >The high C compiler on RTs running AOS appears convinced there is a bug in >loop mode on APC processors [stuff deleted for bandwidth] THE LOOP >LL0012: > lhas r0,0(r3) > lhas r5,2(r3) > inc r3,4 > sis r4,1 > sths r0,0(r2) > sths r5,2(r2) > inc r2,4 > jh LL0012 > mr r0,r0 # no op to fix APC bug > mr r0,r0 # no op to fix APC bug > mr r0,r0 # no op to fix APC bug > lhas r0,0(r3) ..... ..... > >Does anyone know why it does this? The hand coded assembly functions in >our C library don't have any noops in them in similar places. > There have been several versions of the ROMPC chip on the Advanced Processor Card. One or more of them had the following bug: IF, on exiting a loop mode loop, the jump at the end of the loop is in the left half word of a word (full word aligned) AND the jump instruction has a channel holdoff, AND a ROMPC timer update occurs just after the jump THEN: the halfword following the jump is skipped and the next full word is fetched twice, with execution resuming in the second halfword of it, then reverting to the start of it, and continuing on correctly after that. This is rare but catastrophic if it happens. > >-- > --John Carr (jfc@athena.mit.edu) James Moody Adv Workstations Div ; IBM Austin, 2502 aesnet: moody@moody.austin.ibm.com vnet: MOODY at AUSVMQ outside -> ..!cs.utexas.edu!ibmchs!auschs!moody.austin.ibm.com!moody