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.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().
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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
