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. > 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. Toshi
