[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
>> 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:
>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
Doesn't seem likely. Perhaps it means that with clever rounding the
programmer can attain an error no greater than 1/2 the incrementing
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.
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN