gettimeofday seconds rollover problem?

[Thomas Doerfler (nt)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Pavel,

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

wkr,
Thomas.

>   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 imd-systems.de
PGP public key available at:
     http://www.imd-systems.de/pgpkey_en.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFEA/plwHyg4bDtfjQRArSpAJ4x7laAO2JDMrz/ga9dlgA1Mvvv3ACeJafP
ugL2uJ97USfbFjvVrz1geNw=
=2G8C
-----END PGP SIGNATURE-----