Re:“What the Hardware Does” Is Not What Your Program Does: U...
by archgoon on Monday July 15, 2019 @03:14AM
(#20438757)
Guess there's some bigger context that I'm missing here. I wouldn't have expected saying "Understanding how your compiler enforces it's abstract machine is beneficial" would be a controversial position to take.
Re:“What the Hardware Does” Is Not What Your Program Does: U...
by ralfjung on Monday July 15, 2019 @07:36AM
(#20439819)
> Understanding how your compiler enforces it's abstract machine is beneficial
The compiler does not enforce it though. It only implements the abstract machine, and the implementation is only correct for UB-free programs.
Re:“What the Hardware Does” Is Not What Your Program Does: U...
by archgoon on Monday July 15, 2019 @11:22AM
(#20441647)
When you are in UB it's even more interesting to ask what the hardware actually does because the standard will not specify anything.
Re:“What the Hardware Does” Is Not What Your Program Does: U...
by Rusky on Monday July 15, 2019 @02:50PM
(#20443885)
No, that's when it's least interesting to ask what the hardware does. A program with UB will not reliably compile to any particular hardware behavior, so changing unrelated parts of the program or upgrading your compiler can change which hardware behavior you get.
The actual hardware behavior is useful for other purposes, like understanding why the abstract machine is the way it is, or understanding and improving the performance of well-defined programs, but it is not useful at all once you have UB.
I really need to finish my own blog post series on this topic...