= SixtyFourBitTimestamps = [[TOC(Projects/SixtyFourBitTimestamps, depth=2)]] '''Status:''' Implemented. Needs evaluation on various architectures. Prior to the RTEMS 4.8 Releases, RTEMS based all timing on clock ticks. At each clock tick, the current time of day was updated. This meant that the granularity of all time stamps and statistics on per-thread CPU usage were constrained to that of the clock tick. In RTEMS 4.8.0, the lowest level of RTEMS -- the SuperCore (e.g. rtems/cpukit/score) was converted to use POSIX ''struct timespec'' as the format for all timestamps. In conjunction with the addition of the ability of a BSP to report "nanoseconds since last clock tick", RTEMS could now provide nanosecond accurate timestamps and CPU usage statistics. Unfortunately, performing mathematical operations on ''struct timespec'' is painful and slow. This project will consist of the following work: * Baseline Testing * (DONE) Verify all test cases work as baseline. * Capture execution times of RTEMS Timing Tests on reference hardware. * Capture sizes of sample tests. * (DONE) Add a SuperCore object "ScoreTimestamp". * This is an opaque class which will be used by all SuperCore time related functions. * Includes methods will be provided to convert timespec and other standard time formats to and from ScoreTimestamp. * RTEMS has a class to operate upon timespec's so this will be implemented in terms of this. * Direct operations on timespec's will be eliminated throughout RTEMS except as necessary near API calls which operate upon ''struct timespec'' arguments. * Initial implementation will be using ''struct timespec'' and all methods should be simple pass throughs or wrapper of existing functionality in the Timespec math helper class. Note that by adding the class "ScoreTimestamp", we have added a class whose implementation can be changed. * (DONE) Verify all existing test cases still work. * (DONE) Implement alternate version of SuperCore object "ScoreTimestamp" which uses unsigned sixty-four bit integers to represent nanoseconds since the POSIX epoch. * This implementation should be fairly simple as you can do direct math on 64-bit integers. * Do not destroy ''struct timespec'' alternative. The goal is to be able to pick the implementation is for each port to a new CPU architecture to select its preferred method. * Provide configuration similar to other configure/build time parameters in RTEMS to let user select implementation. * Make sure both implementations work. :-D * Post Testing * Verify all test cases work as they did baseline. * Capture execution times of RTEMS Timing Tests again on reference hardware for both implementations. * Capture sizes of sample tests. * Select proper implementation for each target architecture * Evaluation * We anticipate that most of the target architectures RTEMS supports will benefit from using the 64-bit integer version. But RTEMS supports over a dozen architectures so this is certainly not guaranteed. * Work with RTEMS Community to run tests on as many targets as possible to decide which is best choice on each architecture. * Simulators are available for most of the primary target architectures so we will be able to judge the impact of your work.