jfc@athena.mit.edu (John F Carr) (03/28/90)
The high C compiler on RTs running AOS appears convinced there is a bug in
loop mode on APC processors (this version of the processor optimizes loops
of 16 bytes or less by assuming the branch at the end to be taken
[alternatively, call it a 16 byte instruction cache]). With "-S", hc
assembles this function
----------------------------------------------------------------
f(short *a, short *b)
{
memcpy(b, a, 15);
}
----------------------------------------------------------------
to this assembly code:
#--------------| f |-----------------------#
_.f:
mr r0,r2
mr r2,r3
mr r3,r0
cal r4,3(r0)
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)
lcs r5,2(r3)
sths r0,0(r2)
brx r15
stcs r5,2(r2)
.long 0xdf02df00 #Trace table (no stack frame)
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.
--
--John Carr (jfc@athena.mit.edu)moody@moody..austin.ibm.com (03/29/90)
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