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

[Joel Sherrill]

Daron Chabot wrote:
> Madhusudan C.S wrote:
>   
>>
>>     + 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??
>>     
>
> "program the hardware" means just that, configuring a BSP's time-keeping
> hardware. This process might involve setting a counter's frequency
> and/or interrupt generation rate (i.e. the BSP's clock "tick" rate) ,
> for example.
>
>   
Yes but this should not be needed as part of this project.
You will most likely be using a Board Support Package
where this is already supported.  erc32/sis and pc386
already have nanosecond accurate support.
>>     + 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.
>>     
>
> Simple. Just decompose the 64-bit word into two, 32-bit words...
>
>   
How about the native gcc type unsigned long long or the
more portable uint64_t. :-D

uint64_t f( uint64_t x )
{
  return x * 1000;
}

as an exceedingly stupid example.

Add a -S to see the produced assembly code.  It really isn't
that bad on any 32-bit CPU.  And it is a far sight more efficient
that struct timespec math.  Maybe 7-12 instructions on most
of the 32-bit CPU architectures I tried this on.

--joel
> -- dc
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>   


-- 
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