Supporting a right operand for GET_VALUE_AT_ADDRESS would result in more efficient code genated for the hc08, which has a suitable x-relative addressing mode. This would help with aggregate and union accesses.
Philipp Klaus Krause
This one is probably the on eoptimization with the highest gain among teh easy-to-implement ones. It would trasform code like
ldx #_spm_sprites_list, x
Reducing code size from 13 to 5 bytes. And register a is freed, so it can be used for other purposes. This and similar ones are very common code sequences.
I've implemented the case for a right operand literal in #7741. Still left is the more complicated case of your example, where the right operand would be a rematerializable address of a variable (but I did included support in the low-level loadRegIndexed() to handle this possibility later.)
With revision #7856, it will handle rematerializable addresses too. However, loop invariance optimization and/or CSE conspire in some cases to move the addition iCode away from the GET_VALUE_AT_ADDRESS iCode, which then leaves an iTemp live across a larger span and is likely to be spilled. Need to find a good away to either prevent to movement of the original addition iCode or determine that the cast/assignment it is turned into can be safely moved back so that the iTemp can be assigned hx instead of spilling. I'll work on optimizing this after the release.