> it would look something like a = round(fma(a, b, c))
One problem with that is that it makes it look as if the language is more expressive than it is. You might not be able to write, for example
d = round(fma(a, b, c))
because the instruction doing that is a three-register one.
Another example, on x64 (IIRC)
a = a + b + 42
d = d + 4 × e
d = 5 × d // equivalent to d = d + 4 × d
would be valid (being LEA variants), but
a = a + b + c
d = d + 5 × e
d = 7 × d
would not. So, this would be more readable, but I’m not sure it would be easier to write.
You can make it easier to write by allowing ‘obvious’ rewrites such as
a = b + c + d
into
a = b + c
a = a + d
but then, you’re on your way towards a generic programming language, and where do you stop?
It also soon doesn’t get obvious, as it might be possible to avoid the data dependency in the rewrite or to do another ‘obvious’ thing, and move the instruction following that a = a + d up between the two instructions.
One problem with that is that it makes it look as if the language is more expressive than it is. You might not be able to write, for example
because the instruction doing that is a three-register one.Another example, on x64 (IIRC)
would be valid (being LEA variants), but would not. So, this would be more readable, but I’m not sure it would be easier to write.You can make it easier to write by allowing ‘obvious’ rewrites such as
into but then, you’re on your way towards a generic programming language, and where do you stop?It also soon doesn’t get obvious, as it might be possible to avoid the data dependency in the rewrite or to do another ‘obvious’ thing, and move the instruction following that a = a + d up between the two instructions.