Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!maverick.ksu.ksu.edu!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!aglew
From: aglew@dwarfs.crhc.uiuc.edu (Andy Glew)
Newsgroups: comp.arch
Subject: Re: 64 bits for times....
Message-ID: <AGLEW.90Aug25130633@dwarfs.crhc.uiuc.edu>
Date: 25 Aug 90 17:06:33 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> <368@news.nd.edu> <67681@sgi.sgi.com>
Sender: usenet@ux1.cso.uiuc.edu (News)
Organization: University of Illinois, Computer Systems Group
Lines: 26
In-Reply-To: karsh@trifolium.esd.sgi.com's message of 24 Aug 90 21:08:18 GMT

>>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 :^)
>
>Very nice!

Ummmmmm....... 

If CLOCK is accessed across a bus, then Tclockfetch may be affected by
bus traffic.  At least you are reading the correction right there, so
you are likely to, but not guaranteed to, get the same bus traffic.

In general, of course, on modern machines you cannot measure
individual instruction times.  But you might be able to measure the
timing effects of individual instructions on larger code sequences,
with care.

--
Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]