From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,71b19e01eae3a390 X-Google-Attributes: gid103376,public From: rracine@draper.com (Roger Racine) Subject: Re: delay until and GNAT - expand Date: 1999/05/10 Message-ID: #1/1 X-Deja-AN: 476148397 Sender: nntp@news.draper.com (NNTP Master) References: <7gpukr$s82$1@nnrp1.dejanews.com> <7grkbb$cee$1@nnrp1.deja.com> <7grvka$lc5$1@nnrp1.deja.com> <7h1e10$drg$1@nnrp1.deja.com> Organization: Draper Laboratory Newsgroups: comp.lang.ada Date: 1999-05-10T00:00:00+00:00 List-Id: >In article , > rracine@draper.com (Roger Racine) wrote: >> The implementation of "delay", given today's processor speeds, is pretty good. >> I have recently single stepped my way (in assembly) through it, and while I >> did not count the instructions, it had to be on the order of 100 instructions. >> >> So, given a good real-time operating system and a reasonably fast processor, a >> reasonable upper limit would probably be close to 1 microsecond (conservative >> estimate). >> >> I am surprised GNAT documentation does not have this, except that the number >> will be different for every underlying OS. >> >> Roger Racine >This is a highly misleading figure. The completion of a delay, in the sense >that we are talking about, requires a preemptive context switch. To expect >this to happen in 1 microsecond when running over an operating system like >Unix, or even over a light real time executive is wildly optimistic. >I am not sure what you are measuring, but it is quite wrong. We don't document >upper limits for such things in the GNAT manual, because it is impractical to >do so in almost all operating systems contexts, since we depend on the >underlying OS, and this information is not available for the OS. It is not misleading at all. It is a consequence of the speed of today's processors. Back a few years (1983), it was reasonable to expect a simple delay 0.0, which is what the issue is about, to take somewhere near 100 -200 microseconds on a real-time OS. This included the context switch, but not the activities of other tasks. Is this the meaning of the metric in D.8(10,11)? I was somewhat surprised to see numbers, for context switches, in the range of 1 microsecond, but not when I thought of the current speed of processors. And the metric is for processor clock cycles. I am assuming waiting for memory does not count, but even if that is true, the result will not be very much longer. Note that I said, "given a good real-time operating system". That does not include any form of Unix (with the possible exception of LynxOS and any other real-time versions; I have not looked at their documentation recently). I understand why compiler vendors can not document upper limits for host-based systems. I would think that VxWorks and RTEMS could have the bounds documented. And something like "GNAT takes xxx clock cycles + the underlying operating system context switch" would meet the spirit of the RM. I know Wind River publishes their bounds. It is quite reasonable to have users of the metrics look at other documentation, as long as it is referenced. Roger Racine