gettimeofday seconds rollover problem?

Thomas Doerfler (nt) Thomas.Doerfler at
Tue Feb 28 07:23:19 UTC 2006

Hash: SHA1


Pavel Pisa schrieb:
> Excuse me for question, but can be performance problem discussed there.
> "memory" should not affect local variables and parameters cached
> in registers. Only cached values of global variables and data obtained
> through pointers are discarded. Should not be so big problem.
> As for m68k and "cc", I think, that the real bug is in "rtems/score/m68k.h":
> #define m68k_enable_interrupts( _level ) \
>   asm volatile ( "move.w  %0,%%sr " : : "d" (_level));
> This construct clobbers flags and it is required to inform GCC
> about that. The "cc" has to be there
> #define m68k_enable_interrupts( _level ) \
>   asm volatile ( "move.w  %0,%%sr " : : "d" (_level): "cc");

Yes, I would like to see this aswell.

> Linux kernel folks are convinced that "memory" is OK there.
> The Linux uses only these primitives in all IRQ defines for i386 for example:
> __asm__ __volatile__("pushl %0 ; popfl": /* no output */ :"g" (x):"memory", "cc")
> __asm__ __volatile__("cli": : :"memory")
> __asm__ __volatile__("sti": : :"memory")
> Each time with "memory".
> If there is problem with performance, than I suggest to define
> volatile access macros to mark problematic pieces of the code
> #define AS_VOLATILE(x) (*(typeof(&(x)))(&(x)))
> This says, that exactly this access could should be protected
> against move around other volatile constructs.
>   loc_var=AS_VOLATILE(*glob_var_ptr)
>   loc_var=AS_VOLATILE(glob_var)
>   AS_VOLATILE(*glob_var_ptr)=loc_var

Shouldn't it be something like this:

#define AS_VOLATILE(x) (*(volatile typeof(&(x)))(&(x)))

Apart from the missing "volatile", I think this construct has nice
features. It will mark, which accesses are really required to be "safe".
The disadvantage is, that all the locations using
interrupt_disable/enable are required to be revised.

Therefore I would tend again to use the "memory barrier" method as it is
more robust (with the disadvantage of loosing some performance).


>   AS_VOLATILE(glob_var)=loc_var

> But again, I do not think, that it is good to propagate
> volatile to the other code. It start to spread into
> lists and other structures. If there is really
> some busy loop code waiting for global variable change,
> than barrier should be in the loop. If ordering is required
> again memory barrier or explicit volatile or atomic
> accesses are required.
> I hope, that I am not too much off good sense
> with my thoughts there.
> Best wishes
>             Pavel Pisa

- --
- --------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at
PGP public key available at:
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird -


More information about the users mailing list