[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