gettimeofday seconds rollover problem?

[Joel Sherrill]

As usual, Thomas makes good points. 
Thomas Doerfler (nt) wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Joel Sherrill schrieb:
>  
>
>>>>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 agree.  If volatile is sufficient, then I don't want to do anything else.
>>
>>    
>>
>
>I am a bit concerned here. AFAIK the interrupt_enable/disable macros are
>also used in some BSPs and possibly in special user code. I think most
>of us were under the impression that the "volatile" in "asm volatile"
>was sufficent to ensure, that the embraced code would not move out of
>the braced section.
>
>Dealing with the problem by making the relevant variables and data
>structures volatile is definitively the cleaner way to cure our code,
>but it will also involve to review all related code in the BSPs and
>other modules. E.g. termios also uses these macros.
>
>Therefore I really would tend to use the memory barriers, I also belive
>that the performance penalty would not be SO big.
>  
>

Grrr... you are right.  end users assume isr disable/enable are safe. 

>  
>
>>>>You noted that cc needed to be added to the m68k which has to be  CPU
>>>>dependent.
>>>>        
>>>>
>>>
>>>I'm not sure that this is really necessary.  I don't think that the 
>>>compiler can really assume anything about the condition codes anyway.
>>>
>>>      
>>>
>>Then let's ignore this one for now.
>>    
>>
>
>Hm, well, but the "cc" has been specifically added to the inline
>assembly mechanism. When we are tinkering around in this area, doesn't
>it make sense to integrate this aswell? I also would expect that in the
>68K architecture, having valid condition codes live across inline
>assembly is quite improbable, but GCC seems to get a really intelligent
>beast, so if we forget about this potential problem, I think we fall
>into the pit in the future.
>
>  
>

I am not saying the m68k shouldn't be
fixed, just that it can be fixed independently of the other issues.

>wkr, Thomas.
>
>- --
>- --------------------------------------------
>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
>
>iD8DBQFEA1xvwHyg4bDtfjQRAosOAJ9vXuODqAF1xuDiNYVl2rlp/tSrzgCfdJ8x
>rNZt7HwMOG5fxWbRXkhXTPU=
>=COSL
>-----END PGP SIGNATURE-----
>  
>