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: 476162203 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: >> 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 I just did a little checking on Wind Rivers' web site, and I found, for the "MV167C" Motorola 68K board (they do not specify which chip or speed in the web page), "context switching requires only 3.8 microseconds". Not exactly 1 microsecond, but I got the order of magnitude correct. Checking the Motorola site, it turns out the MVME167 board (which I assume is what Wind Rivers was referencing) has a 68040 running at a maximum 33 MHz. I can not find the data supporting my claim of 1 microsecond, but try a PowerPC running at 350 Mhz. Roger Racine