[Bug 1914] Make timestamp implementation choice available for the CPU port

bugzilla-daemon at rtems.org bugzilla-daemon at rtems.org
Fri Sep 16 12:31:57 UTC 2011


https://www.rtems.org/bugzilla/show_bug.cgi?id=1914

--- Comment #2 from Joel Sherrill <joel.sherrill at oarcorp.com> 2011-09-16 07:31:56 CDT ---
The transition to 64-bit time internally has some impact on size and execution
time.  My experimentation led me to conclude that for the primary RTEMS 32 and
64-bit targets, switching to the 64-bit time internally was a wash.  Most of
these targets are reasonably efficient at 64-bit math thanks to gcc and
besides, math on struct timespec, isn't any less complex than the 64-bit code
gcc generates.  The main question for these targets was whether to inline or
not.
I don't have any hard guidelines on how to pick inline versus not inline.

On 16 bit targets, the 64-bit math could be a more negative impact.  The impact
on low code space targets could be too much.

So for ARM, bfin, lm32, m68k, PowerPC, MIPS, SH, SPARC, SPARC64, x86 I would be
prone to switch to inlined 64-bit mode.  Most BSPs for those architectures are
not code space sensitive and the 64-bit operations are going to be similar in
efficiency. My only concerns with that set would be smaller ARMs and Coldfires
from that set.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.



More information about the bugs mailing list