Changes between Version 14 and Version 15 of Developer/OpenProjects

Timestamp:

03/06/08 22:01:49 (16 years ago)

Author:

JoelSherrill

Comment:

/* Add Sixty-Four Bit Timestamps */ Formatting and text cleanup

Developer/OpenProjects

@@ -264 +264 @@
 is painful and slow.  This project will consist of the following work:
 
-# Baseline Testing
-#* Verify all test cases work as baseline.
-#* Capture execution times of RTEMS Timing Tests on reference hardware.
-#* Capture sizes of sample tests.
-
-# Add a SuperCore object "ScoreTimestamp".  
-#* This is an opaque class which will be used by all SuperCore time related functions.
-
-#* 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.
-
-# Verify all existing test cases still work.
-# 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.
-
-# 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.
-
-# 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.
+ *  Baseline Testing
+  *  Verify all test cases work as baseline.
+  *  Capture execution times of RTEMS Timing Tests on reference hardware.
+  *  Capture sizes of sample tests.
+
+ *  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.
+
+ *  Verify all existing test cases still work.
+
+ *  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.
+
+ *  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.
 = Run-Time Tracing =