Since period is a double, it is reasonable to assume that it has a non-zero fractional part. When its value is stored in secs, the fractional part is truncated (the entire value is converted to integer). So if period contained 5.12, sec will contain 5. When an arithmetic operator operates on two different types (such as double and int), the value the "lower rank" operand is converted to the type of the "higher rank" operand. In this case, microsecs will be evaluated as 5.12-5.00.
The only time microsecs will evaluate to zero is when period just happens to contain an exact integer value. > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of Peter Bishop > Sent: Sunday, January 19, 2020 4:20 PM > To: [email protected] > Subject: Re: Metal C using Z/OS macros in C macros > > Hi David, > > Thanks for sharing this snippet. > > I'm not a C person, so I have a dumb question: how does the value of > microSecs not > equal zero? From my naive view it would seem to be the difference between two > things that are the same, with period having been equated to secs in the > previous > statement. I am guessing it may have something to do with microSecs and > period > being doubles where secs is an integer, but it may have nothing to do with > that. > Probably time for RTFM, which begs the question of which FM to R. > > Thanks again in advance for any elaboration while I try to find the answer, > Peter > > On Sun, 19 Jan 2020 18:50:17 +0800, David Crayford <[email protected]> > wrote: > > >The XLC compiler supports named operands in __asm blocks which are much > >easier to understand. > > > >/** Constant for TOD clock unit for a second */ > >static const uint64_t TOD_TIME_SEC = 0xF4240000LLU; > > > >int nanoSleep(double period) { > > int rc; > > int secs = period; > > double microSecs = period - secs; > > uint64_t timerUnits = (secs * TOD_TIME_SEC) + (microSecs * TOD_TIME_SEC); > > __asm (" STIMER WAIT,MICVL=%[micvl]\n" > > " ST 15,%[rc]" > > : [rc]"=m"(rc) > > : [micvl]"m"(timerUnits) > > : "r15"); > > return rc; > >} > > > > > >On 2020-01-18 12:31 AM, Farley, Peter x23353 wrote: > >> The %0 and %1 are parameters to the __asm function, it will do the > >> substitution of > the 2nd and 3rd parameter in the __asm(...) invocation into the %0 and %1 > spots in > the 1st parameter. > >> > >> And I concur with your description - the *invocation* of the "SETUP(...)" > >> macro > will specify the variables to be used and *those* variables are the ones that > need to be > defined, "xx" and "yy" in your example. > >> > >> If the OP (Mr. Reichman) codes the *invocation* of the SETUP macro as > >> follows: > >> > >> SETUP(supstate,key) > >> > >> Then both "supstate" and "key" must be defined C variables. > >> > >> The __asm function does not *define* variables, it just *uses* them. The > >> variables > mentioned in an __asm invocation must already be defined in the C code. > >> > >> Peter > >> > >> -----Original Message----- > >> From: IBM Mainframe Discussion List <[email protected]> On > Behalf Of retired mainframer > >> Sent: Friday, January 17, 2020 11:06 AM > >> To: [email protected] > >> Subject: Re: Metal C using Z/OS macros in C macros > >> > >> In you C code, when you "invoke" the macro, you would provide the values > >> of the > two macro parameters. Something like > >> SETSUP(xx,yy) > >> It is the xx and yy that would show up inside the two parenthetical > >> expressions in > the generated code. Keep in mind that a C macro performs simple text > substitution > long before the actual compilation starts. > >> > >> Based on the generated code you show, you would not terminate the above > invocation with a semicolon. > >> > >> I've never used __asm but is > >> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(xx), "=s"(yy) ) what you > want the compiler to see? > >> > >> Are you using %0 and %1 to mean the macro parameters? That is not the way > >> C > macros work. > >> > >> It looks like there should be a line continuation back slash following the > >> left brace. > I don't think you want the one that follows the right brace since there is no > following > line. > >> > >>> -----Original Message----- > >>> From: IBM Mainframe Discussion List <[email protected]> On > >>> Behalf Of Joseph Reichman > >>> Sent: Friday, January 17, 2020 5:22 AM > >>> To: [email protected] > >>> Subject: Metal C using Z/OS macros in C macros > >>> > >>> Just wondering if I can do something like this > >>> > >>> #define SETSUP(supstate,key) \ > >>> { > >>> __asm ( " MODESET KEY=%0,MODE=%1 \n" : "=s"(supstate), "=s"(key) ) \ > >>> } \ > >>> > >>> Seems like the variables have to be defined > >> ---------------------------------------------------------------------- > >> > >> This message and any attachments are intended only for the use of the > >> addressee > and may contain information that is privileged and confidential. If the > reader of the > message is not the intended recipient or an authorized representative of the > intended > recipient, you are hereby notified that any dissemination of this > communication is > strictly prohibited. If you have received this communication in error, please > notify us > immediately by e-mail and delete the message and any attachments from your > system. > >> > >> ---------------------------------------------------------------------- > >> 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 > > ---------------------------------------------------------------------- > 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
