[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
gettimeofday seconds rollover problem?
- Date: Mon, 27 Feb 2006 21:09:20 +0100
- From: Thomas.Doerfler at imd-systems.de (Thomas Doerfler (nt))
- Subject: gettimeofday seconds rollover problem?
-----BEGIN PGP SIGNED MESSAGE-----
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.
>>> You noted that cc needed to be added to the m68k which has to be CPU
>> 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.
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler Herbststrasse 8
D-82178 Puchheim Germany
email: Thomas.Doerfler at imd-systems.de
PGP public key available at:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----