Don't confuse the format of a parameter to a macro with the format of a hardware facility used by the software. A timer unit (TU) is the interval for updating bit 30 of the interval timer, not bit 31.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Discussion List <[email protected]> on behalf of Paul Gilmartin <[email protected]> Sent: Saturday, February 24, 2018 12:34 AM To: [email protected] Subject: Re: Timer Unis (was: ... time change ...) [I meant "Units".] On Fri, 23 Feb 2018 23:32:07 -0500, Tony Harminc wrote: > >> ... The description of TIMER says: ... >> the low-order bit has a value of one timer unit (approximately 26.04166 >> microseconds). >> >> That has to be right, or else programmers would have noticed. > >I remembered it as bit 23 when I posted, and I first assumed I had just got >it wrong. But the last S/370 POO (and the earliest for S/360 - both on >Bitsavers) do say, with slightly different wording, that it is bit 23 that >is effectively counted down at 300 Hz. > >That first S/360 POO also has this table: > > BIT >POSITION FREQUENCY RESOLUTION > 23 300 cps 3.33 ms > ... > 31 76.8 kc 13 µS > Thanks for the research. I generated a similar table; all the entries differ by a factor of 2. Do they mean a half-cycle: a transition from 0 to 1 or 1 to 0, or a full cycle: a transition from 0 to 1 and back to 0 again? This is close to a flat-out contradiction. TIMER says 26; PoOps says 13. >I'm wondering if the problem relates to the timer itself being a signed integer > ... Doesn't seem likely. Perhaps it means that with clever rounding the programmer can attain an error no greater than 1/2 the incrementing inteval. Will they accept an RCF on the 370 PoOps? >> If so, the External interrupt handler must reload its register before >>another tick is lost ... > >Heh... They thought of that early on. I can't find it in the POO at the >moment, but it is no accident that the fullwords at locations 4C and 54 are >"reserved" by both S/360 hardware and software. Then an MVC for length 8 >from address 50 to address 4C both saves the current value and sets a new >one. Since the timer is not (visibly) updated during instruction execution, >there is no loss of information. > Ah! The poor man's Compare-and-Swap. Works because MVC is block-concurrent, non-interruptible, and MPs were no concern. Overlap? I suppose it doesn't matter and MVC is guaranteed to appear to operate byte-by-byte. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
