[chbot] Compiler optimisation
Helmut Walle
helmut.walle at gmail.com
Fri Jul 2 04:54:39 BST 2021
Regarding that question: if an element of a structure is qualified as
volatile, only that element of any instances should become volatile, not
the entire instance of the structure. Where you need the entire instance
of the structure to be qualified as volatile, this can easily be
achieved by qualifying the instantiation as volatile. Qualifying an
entire instance of a structure makes all elements of that instance
volatile. This is the respective example from the ISO C99 standard:
"
EXAMPLE 2 In:
struct s { int i; const int ci; };
struct s s;
const struct s cs;
volatile struct s vs;
the various members have the types:
s.i int
s.ci const int
cs.i const int
cs.ci const int
vs.i volatile int
vs.ci volatile const int
"
Optimisations tend to be highly implementation-dependent. However, the
ISO C99 standard very clearly says the following about the volatile
qualifier in subsection 6.7.3 (6), and in footnote 116, respectively:
"6 An object that has volatile-qualified type may be modified in ways
unknown to the
implementation or have other unknown side effects. Therefore any
expression referring
to such an object shall be evaluated strictly according to the rules of
the abstract machine,
as described in 5.1.2.3. Furthermore, at every sequence point the value
last stored in the
object shall agree with that prescribed by the abstract machine, except
as modified by the
unknown factors mentioned previously.116) What constitutes an access to
an object that
has volatile-qualified type is implementation-defined."
"116) A volatile declaration may be used to describe an object
corresponding to a memory-mapped
input/output port or an object accessed by an asynchronously
interrupting function. Actions on
objects so declared shall not be ‘‘optimized out’’ by an implementation
or reordered except as
permitted by the rules for evaluating expressions."
So there is a little bit of wiggle room in that last sentence of 6.7.3
(6), "What constitutes an access to an object [...]"
The remaining uncertainty then is is in the questions:
- whether the compiler was developed aiming at ISO C99 conformity in the
first place, and
- even if it was intended to be ISO C99, whether it actually does meet
all of the requirements of the standard.
Is it possible in your case to compile twice with the same optimisation,
while making the smallest possible change to the volatile qualifiers
(e.g., add or remove just one of them), and then comapring the assembly
results? That would be one way of checking potential compiler issues for
the respective optimisation level, and if not too onerous, this might
help more to understand what is going on than looking at overall system
behaviour.
The other general comment is that, while compiler bugs are not unheard
of, they tend to be much rarer than errors in new code under
development... So carefully reviewing your code for other common errors
or risky constructs might be a good idea. I don't know whether this
concern applies in your case, but if you get strange behaviour, how
certain are you that the volatile questions are really causing it?
Kind regards,
Helmut.
On 2/07/2021 12:37, Robin Gilks wrote:
> I've managed to get the change in behaviour down to a single file now
> and have started to sprinkle 'volatiles' about the place.
>
> Question - if an element of a structure is defined as volatile, does
> the instantiation of the structure need to be also or does the whole
> struct effectively become volatile.
>
> Cheers
>
> [...]
More information about the Chchrobotics
mailing list