I know that this not a particularly import piece of information for most purposes, but I was a little surprised to learn it. I checked this with a few different programs and the write sequence for integer assignments was always high byte written first.
It turns out there's probably a good reason for this. Some of the internal timer 16 bit registers have to be written in that order otherwise the intended value may not be written successfully. I tested it for timer registers, and also normal (sram stored) integers as well, and it seems that it always writes this way.
16-bit WRITES of timer1 and similar multi-byte register objects have to be high-byte-first per the datasheet.
IIRC, this essentially freezes the lower byte until IT is written so an unexpected overflow or underflow or match or whatever wont happen. but 16-bit READS are always lower byte first, I tink.
stuart0:
Some of the internal timer 16 bit registers have to be written in that order otherwise the intended value may not be written successfully.
That is precisely why. The C(++) language does not include a fine-grained method to force the the write order. In order to have the best of both (write order preserved and a functional optimizer) the code generator has to be the one to order the writes.
There was a point in the compiler's history when that was not the case.