On 23/09/14 18:27, Gedare Bloom wrote:
On Tue, Sep 23, 2014 at 11:38 AM, Joel Sherrill
<joel.sherr...@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.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
