Michael J. Mahon wrote:
I hope that the optimizer knows enough to leave assembly code
unchanged. I presumed (oops) that UVB meant only that it "passed
through" the optimizer, not that the optimizer attempted to do
anything with it... ;-(
Probably you are right.
It is not true that all stores cause a read access. I don't know
how this myth continues to propagate. (Perhaps it's because of
the "double access" note about the Applesoft POKE function, which
occurs because that store is *always* indexed.)
> Only indexed and indirect indexed stores cause a read access prior
> to the write access (because of a data path conflict in the chip
> which requires another cycle).
>
Thanks. I was indeed thinking that every store instruction causes two
accesses. If not, the solution I gave above seems to be ideal, provided
you use an absolute address, not some expression that has to be
calculated at runtime (which will compile into an y-indexed indirect
store).