What follows is model dependent behavior, not architecture. These instructions are implemented in hardware, so any STCK delaying is done there, not in millicode. Monotonic increasing on a processor is done by delaying, when two STCKs are issued too close together on the same processor. Uniqueness across processors is achieved for STCK and STCKE by storing a processor related value in the low order bits of the resultant timestamp. The method for determining the processor related value is model and configuration dependent.
Line up all the CPUs abreast and issue STCKE (or STCK) simultaneously does not exhibit any delay. However, if you try to infer the execution order of the instructions on the various processors by comparing the entire stored timestamps, you will be misleading yourself. Jim Mulder -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Paul Gilmartin Sent: Monday, February 19, 2024 11:15 PM To: [email protected] Subject: Re: Nanosecond resolution timestamps for HLL's? On Mon, 19 Feb 2024 21:54:56 -0600, Charles Mills wrote: > ... your program or some other unrelated program -- has recently issued an > STCK and your program must spin, consuming CPU cycles, until a unique STCK > ... > >OTOH, if you do need a monotonic value, then you should redesign and recode to >use STCKE. > STCKE is faster than STCK because its granularity if finer and doesn't need to spin as long. How many instructions could have been issued during such a (microcode) STCKE spin? I know, it's model dependent. And a mischievous programmer could contrive to line up all the CPUs abreast and issue STCKE simultaneously to exhibit the worst case. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
