Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!halley!danh
From: danh@halley.UUCP (Dan Hendrickson)
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Message-ID: <957@halley.UUCP>
Date: 24 Aug 90 16:56:22 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>
Reply-To: danh@halley.UUCP (Dan Hendrickson)
Organization: Tandem Computers, Austin, TX
Lines: 32

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...)
>>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.  
[stuff deleted]
>			Bruce Karsh
>			karsh@sgi.com

I believe that the point of the discussion was if you put a cycle timer "very
close" to the CPU, that is if it took a small number of cycles and always took
the same number of cycles (that is, the access did not go across some bus which
various parts of the machine were trying to use at the same time), then you
had a method of accurately measuring the number of cycles to execute an
instruction.  The only caveat on the approach is that all of the cycles must
be in the instruction cache (inst. buffers in Cray terminology).  The key
is to have the "ld.l r1,CLOCK" instruction be a register transfer, not a
memory reference.

Dan Hendrickson
Tandem Computers
Austin, TX