On 24/09/14 07:34, Chris Johns wrote:
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 ?
Something like this:
diff --git a/newlib/libc/include/machine/types.h
b/newlib/libc/include/machine/types.h
index 40a75fa..b7265b9 100644
--- a/newlib/libc/include/machine/types.h
+++ b/newlib/libc/include/machine/types.h
@@ -11,7 +11,7 @@
#endif
#define _CLOCK_T_ unsigned long /* clock() */
-#define _TIME_T_ long /* time() */
+#define _TIME_T_ long long /* time() */
#define _CLOCKID_T_ unsigned long
#define _TIMER_T_ unsigned long
The problem is that, everyone using custom integer types and not time_t will
then probably have a problem. We have to figure out if there are spots in
RTEMS itself. It may help to enable the -Wconversion warnings for this, but I
guess this will trigger hundreds of warnings.
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
The struct bintime is perfectly fine to use.
--
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
