Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!decwrl!pyramid!voder!apple!bcase
From: bcase@apple.UUCP (Brian Case)
Newsgroups: comp.arch
Subject: Re: register windows
Message-ID: <6572@apple.UUCP>
Date: Thu, 29-Oct-87 13:22:50 EST
Article-I.D.: apple.6572
Posted: Thu Oct 29 13:22:50 1987
Date-Received: Wed, 4-Nov-87 01:46:45 EST
References: <201@PT.CS.CMU.EDU> <28200058@ccvaxa> <18903@amdcad.AMD.COM>
Reply-To: bcase@apple.UUCP (Brian Case)
Organization: Apple Computer Inc., Cupertino, USA
Lines: 22

In article <18903@amdcad.AMD.COM> tim@amdcad.UUCP (Tim Olson) writes:
>Yes, we counted the "offset" loads and stores by looking for an add
>(dynamic, at runtime) preceding the load or store which computes into
>the load/store address register.
>
>You are correct that this might be suceptible to code rearrangement --
>however, our internal compiler doesn't schedule loads, and the only
>other code motion is due to loop-invarience [not a problem here] and
>filling branch delay slots [the add, load/store will still be sequential
>at runtime].

Well, it is true that load/store scheduling isn't done, but the offset
computation instruction *will* be factored out of a loop when its source
operands are loop invariant; I have seen the compiler do this.  And then,
if this instruction is the only one in the loop header, and there is only
a branch to the loop header, the offset add will get moved even farther
away.  Anybody wanna write a debugger?  :-)

(garbage
garbage
garbage
so this message won't be rejected)