gettimeofday seconds rollover problem?

[Pavel Pisa]

On Monday 27 February 2006 18:28, Eric Norum wrote:
> On Feb 27, 2006, at 10:18 AM, Joel Sherrill wrote:
> > I liked the suggestion that the memory barriers be added to the ISR
> > level wrappers not the
> > CPU specific implementations.
>
> Till has performance concerns about this.   I kind of agree that if
> it is sufficient that only volatile variables are modified inside a
> disabled section then there's no real need to add the barriers.

I have found, that in the time I have written this,
there has been some progress, but I still think, that
something from my text applies.

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");

else there could be real misbehavior if GCC moves pieces of nonvolatile code
around or reused already computed flags.

I have tried to summarize my thoughts in one of previous e-mails.

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