The code is m68k and the comment is PowerPC.
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.
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.
On September 23, 2014 3:42:48 AM CDT, Sebastian Huber <s...@rtems.org> wrote:
>Module: rtems
>Branch: master
>Commit: 5323247c3148a22baefb1590533972c401f7d745
>Changeset:
>http://git.rtems.org/rtems/commit/?id=5323247c3148a22baefb1590533972c401f7d745
>
>Author: Sebastian Huber <sebastian.hu...@embedded-brains.de>
>Date: Tue Sep 23 08:01:56 2014 +0200
>
>m68k: Use CPU_TIMESTAMP_USE_STRUCT_TIMESPEC
>
>Converting 64-bit nanoseconds values into the common struct timeval or
>struct timespec formats requires a 64-bit division to get the seconds
>value. Performance analysis of high network loads revealed that this
>is
>too costly on PowerPC.
>
>---
>
> cpukit/score/cpu/m68k/rtems/score/cpu.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
>diff --git a/cpukit/score/cpu/m68k/rtems/score/cpu.h
>b/cpukit/score/cpu/m68k/rtems/score/cpu.h
>index d222465..7d164f3 100644
>--- a/cpukit/score/cpu/m68k/rtems/score/cpu.h
>+++ b/cpukit/score/cpu/m68k/rtems/score/cpu.h
>@@ -102,7 +102,7 @@ extern "C" {
> #define CPU_STACK_GROWS_UP FALSE
> #define CPU_STRUCTURE_ALIGNMENT __attribute__ ((aligned (4)))
>
>-#define CPU_TIMESTAMP_USE_INT64_INLINE TRUE
>+#define CPU_TIMESTAMP_USE_STRUCT_TIMESPEC TRUE
>
> /*
>* Define what is required to specify how the network to host
>conversion
>
>_______________________________________________
>vc mailing list
>v...@rtems.org
>http://lists.rtems.org/mailman/listinfo/vc
--joel_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
