Re: delay until and GNAT - expand

[rracine@draper.com (Roger Racine)]

>In article <rracine.12.00086B05@draper.com>,
>  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