Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!news
From: preston@gefion.rice.edu (Preston Briggs)
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Message-ID: <1990Aug24.181208.29581@rice.edu>
Date: 24 Aug 90 18:12:08 GMT
References: <703@exodus.Eng.Sun.COM> <67633@sgi.sgi.com> <957@halley.UUCP>
Sender: news@rice.edu (News)
Organization: Rice University, Houston
Lines: 31

In article <957@halley.UUCP> danh@halley.UUCP (Dan Hendrickson) 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

>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

I'd guess that on modern machines, the Heisenburg Uncertainty
principle comes into play.  You can't measure the time of a single
instruction usefully because the measurement code interferes
with the cache and various pipelines.  We can certainly measure how
long it takes to issue the instruction, but when does it complete?
In a particular context, it'll sometimes depend on the progress
of earlier instructions, etc.  Inserting measurement code changes the
context.

-- 
Preston Briggs				looking for the great leap forward
preston@titan.rice.edu