[rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC

[Chris Johns]

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 ?

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