Re:“What the Hardware Does” Is Not What Your Program Does: U...
by saagarjha on Monday July 15, 2019 @04:10AM
(#20438959)
> the only recourse to understand what the resulting binary actually does is to look at the actual generated assembly
Pretty much, yes.
> I don't get this hostility to understanding the tools you're using.
Don't take me the wrong way: I'm interested in how compilers work, but I accept the concession that I can only really understand their output when my program is free of undefined behavior. It would be nice to have the compiler try its best in the cases where I am violating the rules of the programming language, and often it will do so, but in general I cannot expect this and trying to do so will require making some sort of tradeoff with regards to performance or language power.
Pretty much, yes.
> I don't get this hostility to understanding the tools you're using.
Don't take me the wrong way: I'm interested in how compilers work, but I accept the concession that I can only really understand their output when my program is free of undefined behavior. It would be nice to have the compiler try its best in the cases where I am violating the rules of the programming language, and often it will do so, but in general I cannot expect this and trying to do so will require making some sort of tradeoff with regards to performance or language power.