gnu@hoptoad.uucp (John Gilmore) (02/27/86)
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.arpaark@alice.UucP (Andrew Koenig) (03/01/86)
> 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. That seems silly. The low-order bit of the IBM TOD clock represents one microsecond. Surely you're not saying that the V/6 can execute 52 million STCK instructions per second?
kim@mips.UUCP (Kim DeVaughn) (03/02/86)
> > 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. > > That seems silly. The low-order bit of the IBM TOD clock represents > one microsecond. Surely you're not saying that the V/6 can execute > 52 million STCK instructions per second? The architecture of the 370 thru 309x machines defines the TOD clock to appear as 64 bit register where bits 0-51 are significant to the TOD function. Bit 51 (remember bits are numbered big-endian) is defined to increment at the 1us. rate. Also, "Two executions of STORE CLOCK, possibly on different CPUs in the same configuration, always store different values if the clock is running". And, "The values stored for a running clock always correctly imply the sequence of execution of STORE CLOCK ...". Finally, on UP systems, 0's are stored in bit positions 52-63 when STORE CLOCK is executed; on MP systems, non-zero values may be stored in these positions. What this means implementation-wise is that for an MP system, the value of a "free-running" counter (probably incremented at the machine's cycle rate) is stored in 52-63. Since STORE CLOCK performes a "serialization function" (oversimplification: "flush the pipe" in all CPU's) before the value of the clock is fetched, and again after the value is placed in storage, different CPU's will get unique values of the TOD-clock should "simultaneous" STORE CLOCK's be issued. For a UP machine, it is sufficient to interlock successive accesses to the TOD-clock until after bit 51 has been "ticked". It matters not to the OS if an application whats to burn-up it's time-slice performing such wasteful practices. Note that bit-positions 52-63 cannot be used for timing purposes, but may be used for "sequencing" purposes. /kim -- UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!kim DDD: 408-720-1700 USPS: MIPS Computer Systems Inc, 930 Arques Av, Sunnyvale, CA 94086
herbie@polaris.UUCP (Herb Chong) (03/04/86)
In article <5058@alice.uUCp> ark@alice.UucP (Andrew Koenig) writes: >> 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. > >That seems silly. The low-order bit of the IBM TOD clock represents >one microsecond. Surely you're not saying that the V/6 can execute >52 million STCK instructions per second? quoting from page 4-18 of the IBM S/370 Extended Architecture Principles of Operation (SA22-7085) as amended by TNL SN22-0682: "In the basic form, the TOD clock is incremented by adding a one in bit position 51 every microsecond. In models having a higher or lower resolution, a different bit position is incremented at such a frequency that the rate of advancing the clock is the same as if a one were added in bit position 51 every microsecond. The resolution of the TOD clock is such that the incrementing rate is comparable to the inctruction rate of the model." Herb Chong... I'm still user-friendly -- I don't byte, I nybble.... VNET,BITNET,NETNORTH,EARN: HERBIE AT YKTVMH UUCP: {allegra|cbosgd|cmcl2|decvax|ihnp4|seismo}!philabs!polaris!herbie CSNET: herbie.yktvmh@ibm-sj.csnet ARPA: herbie.yktvmh.ibm-sj.csnet@csnet-relay.arpa, herbie%yktvmh.bitnet@wiscvm ======================================================================== DISCLAIMER: what you just read was produced by pouring lukewarm tea for 42 seconds onto 9 people chained to 6 Ouiji boards.
mat@amdahl.UUCP (Mike Taylor) (03/05/86)
In article <368@mips.UUCP>, kim@mips.UUCP (Kim DeVaughn) writes: > > Note that bit-positions 52-63 cannot be used for timing purposes, but > may be used for "sequencing" purposes. > I know this is a nit, but that is not quite true. It is model-dependent which bit (if any) to the right of bit 51 is incremented for timing purposes. The TOD clock resolution is expected to be similar to the instruction time. On a model with 10 us. instruction time, it would be OK to have a lower resolution, but the time value would be set as if bit 51 were being incremented every microsecond. Zeros must be set to the right of the lowest incremented bit on UP versions. Therefore, a UP (such as the 470 V/6) has no choice but to block until the clock "ticks" in order to guarantee a different value for the STCK. The choice of the minimum resolution (1 us.) means a delay of up to 1 us. An implementor may choose a higher resolution to alleviate this problem, however, the higher resolution must be "correct," in the sense that you can't stuff arbitrary bits on a UP and you can use the higher resolution for timing purposes. Reference "S/370XA Principles of Operation" pp.4-18,4-20. -- Mike Taylor ...!{ihnp4,hplabs,amd,sun}!amdahl!mat [ This may not reflect my opinion, let alone anyone else's. ]