Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!amdcad!tim
From: tim@amdcad.UUCP
Newsgroups: comp.lang.c
Subject: Re: "Cost of Portability" [really deterministic timing]
Message-ID: <16443@amdcad.AMD.COM>
Date: Thu, 30-Apr-87 17:45:21 EDT
Article-I.D.: amdcad.16443
Posted: Thu Apr 30 17:45:21 1987
Date-Received: Sat, 2-May-87 00:51:58 EDT
References: <213@pyuxe.UUCP> <636@edge.UUCP> <1316@frog.UUCP> <658@edge.UUCP> <1287@ubc-cs.UUCP> <698@edge.UUCP>
Reply-To: tim@amdcad.UUCP (Tim Olson)
Organization: Advanced Micro Devices, Inc., Sunnyvale, Ca.
Lines: 25

In article <698@edge.UUCP> doug@edge.UUCP (Doug Pardee) writes:
>I wasn't referring to efficiency.  I was referring to predictability.  I can
>look in my book here and find that on a 10MHz 68000, the instruction
>  MOVE.W 6(A0),D0    will take exactly 1.6+.1w microseconds, for a "w" wait
>state memory.  I haven't the vaguest idea how long it will take to execute
>  temp1 = ptr1->count;   and what's worse, a change to some other part of
>the same module could cause this statement to be faster or slower (as the
>result of global optimization).  Okay?

Good luck "looking in your book" to find the execution time on a 68020
or '030! (Letssee, is the instruction in the cache? Hmmm, maybe the
prefetch buffer... Now, how about the data -- Wait a minute! This can
possibly overlap with the previous instruction execution, now what was
*that*?).

Most, if not all of the newer processors have fairly non-deterministic
execution times; this is the price you pay for higher performance.  This
is not usually a problem, however, since realtime systems usually are
interrupt driven, and you just need to guarantee that the interrupt
response time is sufficient.

	-- Tim Olson
	Advanced Micro Devices
	Processor Strategic Development
	(tim@amdcad.AMD.COM)