Hi,
~ wrote:
I wonder why don't programmers define functions like extensions to the instruction set and then implement everything by hand-optimized assembly for each platform. They would end up with very durable code.
They would end up spending a massive amount of extra time to create software that is less durable, less flexible and has worse performance.
To understand this you need to understand basic/common optimisations (like constant folding, function inlining, etc) that will be prevented by your approach.
For a simple example, imagine this code:
Code:
uint32_t foo(uint32_t x, uint32_t y) {
return (x + 1) * (y + 1);
}
uint32_t bar(uint32_t x) {
return foo(x*4, 9);
}
If you wrote these functions as separate pieces of assembly; it's unlikely (excluding differences in calling conventions - what is/isn't preserved where) that you're going to get anything better than this:
Code:
foo:
push ebx
push edx
lea eax,[eax+1]
lea ebx,[ebx+1]
mul ebx
pop edx
pop ebx
ret
bar:
push ebx
shl eax,2
mov ebx,9
call foo
pop ebx
ret
However, a compiler can inline the functions to get something like this:
Code:
uint32_t bar(uint32_t x) {
uint32_t y = 9;
x *= 4;
return (x + 1) * (y + 1);
}
And then it can do constant folding to get something like this:
Code:
uint32_t bar(int x) {
return x * 40 + 10;
}
And then convert it to something like this:
Code:
bar:
lea eax,[eax*4+eax] ;eax = x * 4 + x = x * 5
lea eax,[eax*8+10] ;eax = (x * 5) * 8 + 10 = x * 40 + 10
ret
For this example it's already obvious that the "hand written functions in assembly" approach is extremely bad for performance (and takes longer to write for one CPU, and takes significantly longer to write for many CPUs).
Cheers,
Brendan