[rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC

[Gedare Bloom]

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

-Gedare

>
> On September 23, 2014 3:42:48 AM CDT, Sebastian Huber <sebh at rtems.org>
> wrote:
>>
>> Module:    rtems
>> Branch:    master
>> Commit:    5323247c3148a22baefb1590533972c401f7d745
>> Changeset:
>> http://git.rtems.org/rtems/commit/?id=5323247c3148a22baefb1590533972c401f7d745
>>
>> Author:    Sebastian Huber <sebastian.huber at embedded-brains.de>
>> Date:      Tue Sep 23 08:01:56 2014 +0200
>>
>> m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
>>
>> Converting 64-bit nanoseconds values into the common struct timeval or
>> struct timespec formats requires a 64-bit division to get the seconds
>> value.  Performance analysis of high network loads revealed that this is
>> too costly on PowerPC.
>>
>> ---
>>
>>  cpukit/score/cpu/m68k/rtems/score/cpu.h |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/cpukit/score/cpu/m68k/rtems/score/cpu.h
>> b/cpukit/score/cpu/m68k/rtems/score/cpu.hindex d222465..7d164f3 100644
>> --- a/cpukit/score/cpu/m68k/rtems/score/cpu.h
>> +++ b/cpukit/score/cpu/m68k/rtems/score/cpu.h
>> @@ -102,7 +102,7 @@ extern "C" {
>>  #define CPU_STACK_GROWS_UP               FALSE
>>  #define CPU_STRUCTURE_ALIGNMENT          __attribute__ ((aligned (4)))
>>
>> -#define CPU_TIMESTAMP_USE_INT64_INLINE TRUE
>> +#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE
>>
>>  /*
>>   *  Define what is required to specify how the network to host conversion
>>
>> ________________________________
>>
>> vc mailing list
>> vc at rtems.org
>> http://lists.rtems.org/mailman/listinfo/vc
>
>
> --joel
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel