Re: Fw: Possible missed optimization opportunity with const?

[David Brown <david at westcontrol dot com>]

On 01/09/16 20:11, Toshi Morita wrote:
> David Brown wrote:
>
> > If it is a hardware register, you normally want to put a
> > "volatile"
>
> > there so that you get exactly the number of reads you want. And if
> > you only want to read it once, then read it only once.=C2=A0
> > Sometimes it is easier to write things in clear and simple code,
> > rather than hoping the> compiler will optimise the unnecessary
> > source code.
>
> There are many cases where there are values at hardware addresses
> which are const.
>
> One example is a hardware configuration register. Many modern
> microcontrollers are fabricated with more interfaces than can be
> physically bonded out in a particular packaging. For example,a
> microcontroller die may have a 4 USB interfaces, 4 SPI, and 4 I2C
> ports. However, this die may be placed in a packaging where there is
> only space for some of the signals to be exposed. So a particular
> chip might have 2 USB interfaces, 2 SPI interfaces, and 2 I2C ports.
> Another chip in the same family might have 1 USB interface, 3 SPI
> interfaces, and 2 I2C ports. So there may be a static hardware
> configuration register which describes the number of interfaces of
> each type for that particular chip.

Yes, I know - I work with such devices myself.  But I'm having trouble 
imagining why you would be likely to read those hardware registers more 
than once (typically during system setup), and also why it would be a 
problem if you did read them twice.  Registers like this are usually no 
more than a couple of clock cycles to access - similar to reading 
on-chip SRAM.  At worst, your system startup might be 50 nanoseconds 
longer than necessary.

It would be a different matter if this were in a tight critical loop, or 
if reading the register had some special effect (such as is sometimes 
the case with hardware registers).

> Another example is mask-programmed ROM or EPROM. These devices are
> usually fairly slow with access times ranging from 125 ns to 450 ns.
> Since these devicesare so slow, it is preferable to avoid unnecessary
> reads to the device. The values in a mask-programmed ROM cannot be
> changed, and the values in an EPROM can only be changed when the
> device is powered off and exposed to UV light for several minutes, so
> the values are effectively const and do not change at runtime.

Usually you can treat such data as const, that's true.  But again, I am 
having a hard time understanding why it might matter if you read the 
data twice (it's not /that/ slow - especially in comparison to calling a 
function in between reads), and why you can't simply store the first 
read in a local variable in cases where it /does/ matter.  And in 
microcontrollers that are fast enough for this to matter, you've 
probably got a cache that can be used.

I'm all in favour of better optimisations, but this looks like a lot of 
effort (for either the gcc developers, or for the programmer) for a 
negligible gain.