Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!cica!iuvax!news!liszt!przemek
From: przemek@liszt.helios.nd.edu (Przemek Klosowski)
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Keywords: timing, high resolution timing
Message-ID: <368@news.nd.edu>
Date: 24 Aug 90 14:25:18 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> <67633@sgi.sgi.com>
Sender: news@news.nd.edu
Organization: University of Notre Dame,  Notre Dame
Lines: 29

In article <67633@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes:
>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...)
 < .. Bruce has the idea of executing instr twice ...>
How about:

       ld.l    r1, CLOCK
       <instr>
       ld.l    r2, CLOCK
       ld.l    r3, CLOCK
       sub.l   r4, r2, r1	; r4 = Tinstr + Tclockfetch
       sub.l   r5, r3, r2	; r5 = Tclockfetch
       sub.l   r6, r4, r5	; r6 = Tinstr
No side effects are involved here. Of course CLOCK cannot be cached or else :^)


--
			przemek klosowski (przemek@ndcva.cc.nd.edu)
			Physics Dept
			University of Notre Dame IN 46556