Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site hoptoad.uucp
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!decwrl!sun!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: net.arch
Subject: IBM 370 TOD clock resolution
Message-ID: <561@hoptoad.uucp>
Date: Thu, 27-Feb-86 02:41:38 EST
Article-I.D.: hoptoad.561
Posted: Thu Feb 27 02:41:38 1986
Date-Received: Sat, 1-Mar-86 04:11:45 EST
References: <156@motatl.UUCP> <530@hoptoad.uucp> <2795@amdahl.UUCP> <650@oakhill.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 19

One further note.  Indeed, the TOD clock is spec'd to never return the
same value twice (assuming you don't reset it).  This was done in various ways
on various IBM and -compatible models.  Some machines would count in 
some large ticks, e.g. milliseconds, but filled in the lower order bits
of the result with the value of an incrementing counter.  The first
STCK (store clock) instruction would return 00000, the next 00001, etc,
until the Big Tick happened and reset the low bits to 0 again.

Before you call that a hack, see what the Amdahl 470 V/6 did.  It just
delayed the STCK instruction until the clock ticked.  I believe the
clock ticked every 52 cycles or something, so the STCK instruction had
an "average" execution time of 26 clocks, depending when you tried versus
when it last ticked.

The "picosecond" resolution is how many bits are allocated to hold the
clock value in the architecture.  A given model can return lots of
lower-order zeros (or garbage) if it doesn't really need them.
-- 
John Gilmore  {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu   jgilmore@lll-crg.arpa