[rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC

[Sebastian Huber]

On 24/09/14 07:34, Chris Johns wrote:
> On 24/09/2014 3:27 pm, Sebastian Huber wrote:
>> On 23/09/14 18:27, Gedare Bloom wrote:
>>> On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
>>> <joel.sherrill at oarcorp.com> wrote:
>>>> The code is m68k and the comment is PowerPC.
>>
>> Sorry, a copy and paste error.
>>
>> I did performance tests on both platforms with FTP transfers to/from
>> "/dev/zero".  I observed roughly 3% processor load in __divdi3() and
>> __moddi3() used by rtems_clock_get_uptime_timeval() and
>> rtems_clock_get_uptime_seconds().
>>
>
> Thanks.
>
>>>>
>>>> Any guidance for the porting guide on what constitutes too expensive?
>>>> There
>>>> should be some general guidelines regarding when to pick a format
>>>> bases on
>>>> that.
>>
>> I think if a target uses __divdi3(), then it is too costly.  The focus
>> on 64-bit nanoseconds neglected that nearly all user API functions use
>> seconds.
>>
>>>>
>>>> Also.. This means that some ports will have 2038 issues at the score
>>>> level.
>>>> We have to address 64 bit time_t at some point.
>>
>> Yes, we should move to 64-bit time_t after the next release or even now.
>>
>
> What is involved ?

Something like this:

diff --git a/newlib/libc/include/machine/types.h 
b/newlib/libc/include/machine/types.h
index 40a75fa..b7265b9 100644
--- a/newlib/libc/include/machine/types.h
+++ b/newlib/libc/include/machine/types.h
@@ -11,7 +11,7 @@
  #endif

  #define        _CLOCK_T_       unsigned long           /* clock() */
-#define        _TIME_T_        long                    /* time() */
+#define        _TIME_T_        long long               /* time() */
  #define _CLOCKID_T_    unsigned long
  #define _TIMER_T_      unsigned long

The problem is that, everyone using custom integer types and not time_t will 
then probably have a problem.  We have to figure out if there are spots in 
RTEMS itself.  It may help to enable the -Wconversion warnings for this, but I 
guess this will trigger hundreds of warnings.

>
>>>>
>>> It was proposed to use the bintime instead of 64-bit time_t (see [Bug
>>> 2180] New: _TOD_Get_with_nanoseconds() is broken on SMP)
>>
>> The bintime is
>>
>> struct bintime {
>>      time_t    sec;
>>      uint64_t frac;
>> };
>>
>> Most operations with timestamps use subtraction and comparison.  On most
>> 32-bit architectures this is efficient even for 64-bit values.  The
>> problem is the division operation.
>>
>
> I am not sure understand what you are saying. Are you implying a performance
> issue with bintime because it has a multiple to convert or are you saying
> bintime ok to use ?
>
> Chris

The struct bintime is perfectly fine to use.

-- 
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.