On Jan 13, 2011, at 10:37, Glenn Knickerbocker wrote:
>
> Naive question: What would it take for DELAY to take advantage of
> Extended-TOD-Clock to push this problem out a few millennia?
>
I believe a new iteration of hardware. While PoOp makes some
suggestion that the new upper byte is slated for extension of the
range of the clock, I believe that nowadays STCKE simply clears
it (and it's ignored in the Clock Comparator?)
Likewise, STCKCONV ignores the high byte for STCKE format input.
It would be a better design for STCKCONV to report an error if
the high byte is nonzero.
On Jan 13, 2011, at 15:08, Rob van der Heij wrote:
>
> I must be more dumb than usual today, but what's the role of a gate
> that is never triggered? It would never shut the pipeline so you could
> just take it out?
>
It might have been simpler for the coder to set the expiration to
now +999,999,999 seconds than to take out the GATE, while making
the tenuous assumption that the system would not run for 30+ years
without an IPL or some sort of restart.
As a novice, I desire all the help that tools will give me. While
the Author's Edition says:
You can wait until any time in the future, as long as the
time-of-day clock has not changed sign.
it's moot concerning the consequences of requesting a wait to
a time when the time-of-day clock "has .. changed sign". I'd
consider it a higher quality implementation if DELAY were to
report an error when the AL (or whatever instruction computes
the comparator value) set the condition code for carry-out from
Bit 0 rather than merely completing immediately.
(Isn't the TOD clock considered to be unsigned? And I see no
problem when Bit 0 changes from 0 to 1; only when it changes
from 1 to 0.)
-- gil
