[chbot] Compiler optimisation

Sat Jul 3 00:47:52 BST 2021

Many thanks to the contributions - I'm making progress.

Turns out I have 2 issues with the jpeg encoder.
1. A library function (closed source, no idea what it does inside) gets
clobbered when optimise is cranked up, looks like an undocumented 'feature'
of just how large a working area is required by the encoder and what I had
allocated was being overflowed. (I found a worked example that used much
larger buffers than I had and that works fine, unfortunately the
undocumented bit is how the buffer size is determined).

2. The module that works OK with optimisation off is full of DMA interrupt
hazards! The stm32f7 jpeg hardware encoder/decoder  (
https://www.st.com/resource/en/application_note/dm00356635-hardware-jpeg-codec-peripheral-in-stm32f7677xxx-and-stm32h743534555475750a3b3b0xx-microcontrollers-stmicroelectronics.pdf)
is fast but it looks like the silicon has been borrowed from elsewhere and
it has a lot of constraints - like aligned and uncached memory otherwise it
just silently fails. I'm working my way through this module to try and
understand where it errors. Basically an RGB buffer is converted to YCbCr
(which is OK, despite my original thoughts) and the MCU (Minimum Coded
Unit) so generated is DMAed into the JPEG engine and it coughs out JPEG
data (again via DMA) into another buffer. It goes round and round
processing the original bmp image until a new image 30th the size is
created!

I'm hoping that a bit of quiet time with the code in front of me will
reveal where the problems lie.

Cheers

On Fri, Jul 2, 2021 at 3:56 PM Helmut Walle <helmut.walle at gmail.com> wrote:

> 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
> >
> > [...]
>
> _______________________________________________
> Chchrobotics mailing list Chchrobotics at lists.ourshack.com
> https://lists.ourshack.com/mailman/listinfo/chchrobotics
> Mail Archives: http://lists.ourshack.com/pipermail/chchrobotics/
> Meetings usually 3rd Monday each month. See http://kiwibots.org for
> venue, directions and dates.
> When replying, please edit your Subject line to reflect new subjects.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ourshack.com/pipermail/chchrobotics/attachments/20210703/23a1923a/attachment.html>