gettimeofday seconds rollover problem?

Eric Norum norume at aps.anl.gov
Thu Feb 23 20:55:15 UTC 2006


On Feb 23, 2006, at 2:24 PM, Till Straumann wrote:

> One moment, folks -- I'm not sure the "memory" approach is best
> for all architectures. On CPUs with many registers, making
> rtems_interrupt_enable()/disable a real subroutine might be cheaper.
>
> In any case, I believe that declaring the relevant global variables
> 'volatile' is the correct way to deal with this problem.

I agree that  _TOD_Current and _TOD_Seconds_since_epoch should be  
declared volatile since they are certainly updated by code in a way  
that is not apparent to the optimizer.  However, I'm concerned that  
there are other places where code may be unexpectedly hoisted outside  
an enable/disable pair.   Adding the "memory" seems prudent.

I'm not sure that I understand the "many registers" problem you refer  
to.  Have a look at the m68k code in question:
> (gdb) disassem gettimeofday
> Dump of assembler code for function gettimeofday:
> 0x00127d8c <gettimeofday+0>: movel %d2,%sp at -
> 0x00127d8e <gettimeofday+2>: moveal %sp@(8),%a0
> 0x00127d92 <gettimeofday+6>: tstl %a0
> 0x00127d94 <gettimeofday+8>: beqs 0x127dcc <gettimeofday+64>
> 0x00127d96 <gettimeofday+10>: movel #1792,%d0
> 0x00127d9c <gettimeofday+16>: movel %d0,%d1
> 0x00127d9e <gettimeofday+18>: movew %sr,%d0     
> <<<<<<<<<<<<<<<<<<<<<d0 set here
> 0x00127da0 <gettimeofday+20>: orl %d0,%d1
> 0x00127da2 <gettimeofday+22>: movew %d1,%sr
> 0x00127da4 <gettimeofday+24>: movel 0x219e06  
> <_TOD_Seconds_since_epoch>,%d1
> 0x00127daa <gettimeofday+30>: movel 0x219ee2 <_TOD_Current+24>,%d2
> 0x00127db0 <gettimeofday+36>: movew %d0,%sr      
> <<<<<<<<<<<<<<<<<<<<d0 used here
> 0x00127db2 <gettimeofday+38>: addil #567993600,%d1
> 0x00127db8 <gettimeofday+44>: movel %d1,%a0@
> 0x00127dba <gettimeofday+46>: movel 0x219f32  
> <_TOD_Microseconds_per_tick>,%d0
> 0x00127dc0 <gettimeofday+52>: mulsl %d2,%d0
> 0x00127dc4 <gettimeofday+56>: movel %d0,%a0@(4)
> 0x00127dc8 <gettimeofday+60>: clrl %d0
> 0x00127dca <gettimeofday+62>: bras 0x127ddc <gettimeofday+80>
> 0x00127dcc <gettimeofday+64>: jsr 0x185270 <__errno>
> 0x00127dd2 <gettimeofday+70>: moveal %d0,%a0
> 0x00127dd4 <gettimeofday+72>: movel #14,%a0@
> 0x00127dda <gettimeofday+78>: moveq #-1,%d0
> 0x00127ddc <gettimeofday+80>: movel %sp at +,%d2
> 0x00127dde <gettimeofday+82>: rts

Notice that the compiler is quite happy to use after the enable/ 
disable the value which was saved in d0 before the enable/disable.   
How has adding the "memory" hurt anything?


Even if we don't add "memory" to the list of clobbered registers I  
think that we should add "cc" since the condition codes really do get  
mangled by the interrupt enable/disable operation.


-- 
Eric Norum <norume at aps.anl.gov>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793





More information about the users mailing list