Open Bananattack opened 5 years ago
As far as I can tell, the remaining issue is that any nested side-effects to the destination operand are currently not validated to only happen once.
eg.
// This:
dest[x++] = a + b + c;
// Should be rewritten into either:
// dest[x] = a;
// dest[x] += b;
// dest[x++] += c;
//
// or:
//
// dest[x] = a;
// dest[x] += b;
// dest[x] += c;
// x++;
//
// but instead becomes:
// dest[x++] = a;
// dest[x++] += b;
// dest[x++] += c;
Right now, it is only possible to use pre/post-increment in either a top-level position, or as part of an addressing mode.
It would neat if pre-increments and post-increments were allowed in any subexpression. This would mean the number of intermediate statements needed can be greatly simplified, and it will still sequence the correct thing.
The Z80 + GB example shows how it can be useful for writing code that takes advantage of specialized instructions when they exist (
hl
post-increment indirect on GB). However, it still generates valid compiling code if the specialized instruction does not exist, but another valid sequence of instructions that does the same thing is found.The sequencing will try to be as close as possible to the site of use, rather than delaying side-effects until the full outermost expression is finished. So things can be written with left-to-right evaluation in mind, no weird "sequence points" to figure out.
This would also be possible:
Cutting down on the number of intermediate statements needed to use hl-assignment operators. Some of these are subjectively less readable than separate statements, but I think it should be up to the user's discretion to write separate assignment statements or do a one-liner, and the compiler's job to do what it can to allow it.