On 01/09/16 21:11, Toshi Morita wrote:
David Brown wrote:
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've worked on one platform with a dual ARM7 running at 100 Mhz and no cache.
ROMs had a cycle time of 450 ns, and the processor has a cycle time of 10 ns.
So it's 45 clock cycles to access ROM.
In cases like that, you can do your caching manually. Just read the rom
value once, and keep the value in a local variable - then it will stay
in a local register. If you have a lot to read and re-use, copy a block
to SRAM. This is something that the compiler could never do on its own
- you have to write it in the code.
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.
If you look at my original message, you will see that this optimization is
already implemented and works for the case where pfoo = &foo.
It fails when foo is replaced with a (const int * const) address.
I suspect when the C front-end parses (const int * const)0x1234, it fails
to apply the const_tree attribute to the subtree, and this is why the
optimization is failing.
This was already explained to you by Florian - the compiler cannot make
the optimisation you want, because it does not know that the object at
address 0x1234 is truly constant. The "const" in the pointer here can
only tell the compiler that /you/ will not try to change its value.
This is different from the case where you define pfoo from the address
of foo, because you have defined foo to be constant - now the compiler
knows it cannot change, and can optimise accordingly.
To be able to get the kind of optimisation you are asking for, you would
need to be able to tell the compiler that the thing pfoo points to is
really constant - that would need a new __attribute__ or similar
extension. Alternatively, you would need a new __attribute__ to let you
declare a const foo at a specific address (this might be easier, since
the relevant __attribute__ already exists for avr-gcc).
