Duration for GNAT on ARM

Duration for GNAT on ARM

[Simon Wright]

You use -gnatS to get GNAT to output a representation of package
Standard.

If you do this with a native compiler, you get (typically)

   type Duration is delta 0.000000001
     range -((2 ** 63 - 1) * 0.000000001) ..
           +((2 ** 63 - 1) * 0.000000001);
   for Duration'Small use 0.000000001;

However, if I do this with both GNAT GPL 2014 and FSF GCC 4.9.1
cross-compiling to arm-eabi for the STM32F4 family (Cortex M4), I get

   type Duration is delta 0.020
     range -((2 ** 31 - 1) * 0.020) ..
           +((2 ** 31 - 1) * 0.020);
   for Duration'Small use 0.020;

I can understand the 32-bit vs 64-bit part - a misguided attempt at
efficiency, perhaps - but who gets to say that the clock runs at 50 Hz?
On the STM32's with STMicroelectronics' HAL, the tick is 1 kHz.

Re: Duration for GNAT on ARM

[Dmitry A. Kazakov]

On Tue, 23 Dec 2014 21:21:57 +0000, Simon Wright wrote:

> You use -gnatS to get GNAT to output a representation of package
> Standard.
> 
> If you do this with a native compiler, you get (typically)
> 
>    type Duration is delta 0.000000001
>      range -((2 ** 63 - 1) * 0.000000001) ..
>            +((2 ** 63 - 1) * 0.000000001);
>    for Duration'Small use 0.000000001;
> 
> However, if I do this with both GNAT GPL 2014 and FSF GCC 4.9.1
> cross-compiling to arm-eabi for the STM32F4 family (Cortex M4), I get
> 
>    type Duration is delta 0.020
>      range -((2 ** 31 - 1) * 0.020) ..
>            +((2 ** 31 - 1) * 0.020);
>    for Duration'Small use 0.020;
> 
> I can understand the 32-bit vs 64-bit part - a misguided attempt at
> efficiency, perhaps - but who gets to say that the clock runs at 50 Hz?

E.g. those who have time source derived from timer interrupts.

> On the STM32's with STMicroelectronics' HAL, the tick is 1 kHz.

But does the RTL assumed by the compiler use this clock?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Duration for GNAT on ARM

[J-P. Rosen]

Le 23/12/2014 23:42, Dmitry A. Kazakov a écrit :
> However, if I do this with both GNAT GPL 2014 and FSF GCC 4.9.1
>> cross-compiling to arm-eabi for the STM32F4 family (Cortex M4), I get
>> 
>>    type Duration is delta 0.020
>>      range -((2 ** 31 - 1) * 0.020) ..
>>            +((2 ** 31 - 1) * 0.020);
>>    for Duration'Small use 0.020;
>> 
>> I can understand the 32-bit vs 64-bit part - a misguided attempt at
>> efficiency, perhaps - but who gets to say that the clock runs at 50 Hz?
Duration'small is not related to the accuracy of the hardware clock,
it's just the elementary step for time. Ada.Real_Time might be more
useful for you.

-- 
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

Re: Duration for GNAT on ARM

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

>> On the STM32's with STMicroelectronics' HAL, the tick is 1 kHz.
>
> But does the RTL assumed by the compiler use this clock?

I'm writing the RTS, it should be up to me to decide the granularity!

Reading the source, one approach would be to tell the compiler to use a
64-bit clock: towards the end of system.ads, I have

   Duration_32_Bits          : constant Boolean := True;

so I could set it to False and put up with some 64-bit arithmetic in
Ada.Real_Time.

Re: Duration for GNAT on ARM

[Simon Wright]

"J-P. Rosen" <rosen@adalog.fr> writes:

> Le 23/12/2014 23:42, Dmitry A. Kazakov a écrit :

Actually, it was me.

>> However, if I do this with both GNAT GPL 2014 and FSF GCC 4.9.1
>>> cross-compiling to arm-eabi for the STM32F4 family (Cortex M4), I get
>>> 
>>>    type Duration is delta 0.020
>>>      range -((2 ** 31 - 1) * 0.020) ..
>>>            +((2 ** 31 - 1) * 0.020);
>>>    for Duration'Small use 0.020;
>>> 
>>> I can understand the 32-bit vs 64-bit part - a misguided attempt at
>>> efficiency, perhaps - but who gets to say that the clock runs at 50
>>> Hz?

> Duration'small is not related to the accuracy of the hardware clock,
> it's just the elementary step for time. Ada.Real_Time might be more
> useful for you.

This is for a Ravenscar RTS, so I have to use Ada.Real_Time.

in GNAT, Ada.Real_Time.Time and Time_Span are both new Durations.

I find the "elementary step for time" concept somewhat confusing. I have
a clock which ticks every millisecond, but the 32-bit Standard.Duration,
Ada.Real_Time.Time, and Ada.Real_Time.Time_Span all have the same
granularity of 20 ms!

Oh. AdaCore's arm-eabi Ada.Real_Time works with very low-level stuff to
provide for 50 years of running, and doesn't use Duration. For the
present work, I'm quite happy not to meet that requirement!

It would be good to work out why my clock is running fast by almost a
factor of 2 ...

Re: Duration for GNAT on ARM

[Simon Wright]

Simon Wright <simon@pushface.org> writes:

> "J-P. Rosen" <rosen@adalog.fr> writes:
>
>> Le 23/12/2014 23:42, Dmitry A. Kazakov a écrit :
>
> Actually, it was me.
>
>>> However, if I do this with both GNAT GPL 2014 and FSF GCC 4.9.1
>>>> cross-compiling to arm-eabi for the STM32F4 family (Cortex M4), I get
>>>> 
>>>>    type Duration is delta 0.020
>>>>      range -((2 ** 31 - 1) * 0.020) ..
>>>>            +((2 ** 31 - 1) * 0.020);
>>>>    for Duration'Small use 0.020;
>>>> 
>>>> I can understand the 32-bit vs 64-bit part - a misguided attempt at
>>>> efficiency, perhaps - but who gets to say that the clock runs at 50
>>>> Hz?
>
>> Duration'small is not related to the accuracy of the hardware clock,
>> it's just the elementary step for time. Ada.Real_Time might be more
>> useful for you.
>
> This is for a Ravenscar RTS, so I have to use Ada.Real_Time.
>
> in GNAT, Ada.Real_Time.Time and Time_Span are both new Durations.
>
> I find the "elementary step for time" concept somewhat confusing. I have
> a clock which ticks every millisecond, but the 32-bit Standard.Duration,
> Ada.Real_Time.Time, and Ada.Real_Time.Time_Span all have the same
> granularity of 20 ms!

I get the point, now.

I've put this in Ada.Real_Time:

      Time_Unit  : constant := 1.0e-9;

      [...]

   private
      type Time_Base is
        delta 0.000000001
        range -((2 ** 63 - 1) * 0.000000001) .. +((2 ** 63 - 1) * 0.000000001);
      for Time_Base'Small use 0.000000001;
      --  Replaces Duration, which has a different representation on
      --  systems with 32-bit Duration.

      type Time is new Time_Base;

      [...]

      type Time_Span is new Time_Base;

      [...]

      Time_Span_Unit  : constant Time_Span := 1.0e-9;

      Tick : constant Time_Span := 0.001;

> Oh. AdaCore's arm-eabi Ada.Real_Time works with very low-level stuff to
> provide for 50 years of running, and doesn't use Duration. For the
> present work, I'm quite happy not to meet that requirement!

They're based on the processor high-res time base, which is typically a
32-bit register that overflows after 7 seconds ... so lots of work
extending that to the 50 years requirement.

When I worked with PowerPC boards (from Radstone, now part of GE
Intelligent Platforms) the on-board crystals were good for 50 ppm, about
5 seconds/day, so after 50 years that's over a day!

My present implementation is only valid up to 10 days. Quite good enough
for school projects, I think, but will consider extending.

> It would be good to work out why my clock is running fast by almost a
> factor of 2 ...

With the above changes, all is good.