Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!mips!sgi!karsh@trifolium.esd.sgi.com
From: karsh@trifolium.esd.sgi.com (Bruce Karsh)
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Message-ID: <67633@sgi.sgi.com>
Date: 24 Aug 90 02:36:10 GMT
References: <5539@darkstar.ucsc.edu> <13285@yunexus.YorkU.CA> <30728@super.ORG> <26012@bellcore.bellcore.com> <11187@alice.UUCP> <1990Aug23.022416.14798@sco.COM> <703@exodus.Eng.Sun.COM>
Sender: karsh@trifolium.esd.sgi.com
Reply-To: karsh@trifolium.sgi.com (Bruce Karsh)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 34

seanf@sco.COM writes:
>If you want to find out *exactly* how
>many clock-ticks an instruction takes, you do something like:
>
>       ld.l    r1, CLOCK
>       <instr>
>       ld.l    r2, CLOCK
>       sub.l   r3, r1, r2

In article <703@exodus.Eng.Sun.COM> rtrauben@cortex.Eng.Sun.COM (Richard Trauben) writes:
>Nope. (close but no cigar...)
>You just measured the execution time sum of TWO instructions:
><instr> PLUS <ld> execution time where the <ld> includes bus 
>arbitration and memory access time to the TOD clock resource.  

How about:

       ld.l    r1, CLOCK
       <instr>
       ld.l    r2, CLOCK
       sub.l   r3, r1, r2	; r3 = Tinstr + Tclockfetch
       ld.l    r1, CLOCK
       <instr>
       <instr>
       ld.l    r2, CLOCK
       sub.l   r4, r1, r2	; r4 = 2*Tinstr + Tclockfetch
       sub.l   r5, r3, r4	; r5 = r4 - r3 = Tinstr

Of course, executing <instr> more than once may have some timing side effects
with respect to the cache.  Hence, you should probably ensure that this
code and all the arguments to <instr> are already in the cache.

			Bruce Karsh
			karsh@sgi.com