Path: utzoo!attcan!uunet!snorkelwacker!bloom-beacon!bloom-beacon!athena.mit.edu!jfc
From: jfc@athena.mit.edu (John F Carr)
Newsgroups: comp.sys.ibm.pc.rt
Subject: APC loop mode bug?
Message-ID: <1990Mar28.144727.15576@athena.mit.edu>
Date: 28 Mar 90 14:47:27 GMT
Sender: news@athena.mit.edu (News system)
Reply-To: jfc@athena.mit.edu (John F Carr)
Organization: Massachusetts Institute of Technology
Lines: 50


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)