[rtems commit] m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC

[Sebastian Huber]

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

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

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

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