64 bit timestamps was Re: I want to participate in GSoC from RTEMS

[Joel Sherrill]

Madhusudan C.S wrote:
>
>
>     The issue at hand is that RTEMS does need the capability
>     to give as accurate as possible time stamps at the API
>     level.  Given that we are lean and mean, we don't waste
>     precision -- if it is available at the bottom of the software,
>     the user is going to get portable access to it.
>
>     Some background for Madhusudan.
>
>     + Unlike GNU/Linux.  Most RTEMS users have their own
>     unique hardware platforms and provide their own device
>     drivers.  Each Board Support Package (BSP) includes a
>     clock tick device driver.  This is the source of all time
>     information in RTEMS.
>
>
>     + The user writes an application and configures many
>     tunable parameters including the nanoseconds per
>     clock tick.
>
>  
> Fine understood. 
>
>     + The BSP's clock tick driver uses this to program the
>     hardware.
>
>
> "This program" confused me a bit. Please help me. Is it the program 
> that I have to write now or user's application??
>
>     + In RTEMS prior to 4.8, all time was based on the "clock tick".
>     When a tick interrupt occurs, the interrupt handler calls
>     rtems_clock_tick to "increment the time by the configured
>     nanoseconds per tick"
>
>     + In 4.8 and newer, the same use of tick but now we can
>     ask the BSP for "nanoseconds since last tick" and get a
>     more accurate timestamp.  This is an optional capability
>     and RTEMS assumes 0 nanoseconds when this is not
>     available and you end up with the pre-4.8 time is only
>     accurate to a clock tick behavior.
>
>
> Thanks a lot I understood this part.
>
>     + When this change was made, the internal time structure
>     was changed to struct timespec.  This is nanosecond accurate
>     but terribly inefficient to do math with.  Some RTEMS applications
>     run on space based hardware which is VERY VERY slow to
>     survive radiation.  At 10-15 Mhz (YEP!) some time operations
>     went up by ~20-30 microseconds.  Since we use this to timestamp
>     context switches, this is just flat horrible.
>
>     + On 32-bit CPUs, Sixty-four bit math is heavier than 32-bit math
>     but it is WAY better than struct timespec math.
>
>
> Sorry I did not understand this part. How can you do Sixty-four bit 
> math on a 32-bit CPUs. Please guide me.
>  
>
>     Right now, we just declare struct timespecs in the supercore
>     to hold time.  In retrospect, this was a bad decision and not
>     in keeping with the rest of RTEMS.  We usually add "classes"
>     and provide very opaque routines to deal with things.  So
>     this is adding a new class and cleaning up things to use it.
>
>
> Ok I roughly understood what you are trying to explain me in theory.  
> I still donno how it can be implemented in the code. I hope that is 
> the whole part of this project for GSoC, planning and designing how to 
> do it and accomplishing it through code.
>
This is indeed the crux of the project.  RTEMS is layered up from
small classes into larger composite, aggregated classes.

There is already a set of math operations on struct timespec.
See *timespec* in the cpukit/score/src and the corresponding
inline (.inl) and .h files. 

The 64-bit math is the easy part here since gcc directly supports
64-bit integers on all targets -- even 16 bit ones!!

Let me see if I can make this settle in..

API level:                Classic API TOD or POSIX timeval or POSIX 
timespec etc
SuperCore level:   SuperCore TOD is a struct timespec

We want

SuperCore level TOD to be implemented as a SuperCore Timestamp
and conditional compilation that allows SuperCore Timestamp to
either be implemented using struct timespec or uint64_t timestamps
with no one using SuperCore TOD to know the difference.  We want
SuperCore TOD and Timestamp to be completely opaque to their
users.

So you are adding SuperCore Timestamps and it has alternate
implementations -- struct timespec or uint64_t depending upon
CPU architecture.  The individual ports in score/cpu will be able
to select their implementation.  Some CPU families may do better
with struct timespec math, others with 64-bit ints.
>
>     There are 18 files in the supercore which reference
>     struct timespec.  RTEMS has only 1 function per file.
>     A few of those are .h files.
>
>
> Yeah I saw most of the files. Thanks a lot for giving me the pointers, 
> otherwise I would have spent a lot of time searching these files.
>  
>
>     This is not a huge project -- but it is a critical one.
>     I really want to see this happen and will help you
>     write up a proposal.
>
>     FWIW this is important enough that I was tempted to
>     start it when I updated the description for SOC.
>     It is a critical item.
>
>  
> I hope I can make this project happen this summer. I want to be a part 
> of RTEMS from now onwards(I think I am already and I hope community 
> would accept this), not just this summer or during GSoC duration. 
> Please help me get going guys.
>
We are trying.  :)
>
> -- 
> Thanks and regards,
> Madhusudan.C.S
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985