Re: delay until and GNAT - expand

[rracine@draper.com (Roger Racine)]

>>  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