Hacker News Reader

Comment by steveklabnik | Hacker News Reader

> At the end of the day, assembly code is going to execute, and that assembly code is going to (despite the authors protestations to the contrary) have well defined memory of one value or another.

The point is that you may not get the assembly you assume you’re going to get. Like the example shows, it may never even generate something that accesses the value at all.

View on HN

Yes, but that doesn't mean that what the hardware does is irrelevant.

That’s true. You have to understand that abstract machine, what it guarantees, and how that relates to your hardware and what it guarantees.

I really need to finish my own blog post series on this topic...

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.

> 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.

When you are in UB it's even more interesting to ask what the hardware actually does because the standard will not specify anything.

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.

It's interesting to me, and it's interesting to the first person in this thread. I'm sorry that you feel that were wasting our time.

Reply on news.ycombinator.com