3 ms·

Okay, you're talking about OoO execution here, and you're right that this can be hard to reason about (in terms of stalls/latencies), however that's orthogonal

Okay, you're talking about OoO execution here, and you're right that this can be hard to reason about (in terms of stalls/latencies), however that's orthogonal to microcode translation.

vardump 7y ago
OoO and the fact that CPUs really are free to do whatever transformations they deem fit, as long as the end result within limits of memory model is same.
- jcranmer 7y ago
  The CPU must conform to the strictures of the ISA, which is a much more stringent specification than the abstract machines of most language specifications. In particular, the state of registers and flags at any given time need to be preserved, even in the presence of external interrupts. Note that several decades ago, there were processors that weren't capable of actually keeping the state correct after a processor exception, so if you got a division-by-0 error, your program counter had advanced by 30 or so. (This is, I believe, part of the reason why traps are undefined behavior in C: if your processor can't guarantee any state after a machine trap, it's impossible to implement a programming language that has even the loosest guarantees).
  - vardump 7y ago
    > The CPU must conform to the strictures of the ISA, which is a much more stringent specification than the abstract machines of most language specifications. In particular, the state of registers and flags at any given time need to be preserved, even in the presence of external interrupts. https://en.wikipedia.org/wiki/Tomasulo_algorithm https://en.wikipedia.org/wiki/Tomasulo_algorithm. So no, the consistent serialized ISA-conforming state might be reconstructed by replaying after the exception (interrupt) arrives. Alternatively, interrupt might be served only after execution reaches the next checkpoint.
overgard 7y ago
I don't understand how you can acknowledge the cpu is literally rewriting your code on the fly by changing the order of operations and making things massively parallel and rewriting things in a proprietary language, while holding the belief that "microcode is really not that different from assembly". At least you can inspect what a C compiler emits to assembly.

Okay, you're talking about OoO execution here, and you're right that this can be hard to reason about (in terms of stalls/latencies), however that's orthogonal to microcode translation.

vardump 7y ago

OoO and the fact that CPUs really are free to do whatever transformations they deem fit, as long as the end result within limits of memory model is same.

jcranmer 7y ago
The CPU must conform to the strictures of the ISA, which is a much more stringent specification than the abstract machines of most language specifications. In particular, the state of registers and flags at any given time need to be preserved, even in the presence of external interrupts. Note that several decades ago, there were processors that weren't capable of actually keeping the state correct after a processor exception, so if you got a division-by-0 error, your program counter had advanced by 30 or so. (This is, I believe, part of the reason why traps are undefined behavior in C: if your processor can't guarantee any state after a machine trap, it's impossible to implement a programming language that has even the loosest guarantees).
- vardump 7y ago
  > The CPU must conform to the strictures of the ISA, which is a much more stringent specification than the abstract machines of most language specifications. In particular, the state of registers and flags at any given time need to be preserved, even in the presence of external interrupts. https://en.wikipedia.org/wiki/Tomasulo_algorithm https://en.wikipedia.org/wiki/Tomasulo_algorithm. So no, the consistent serialized ISA-conforming state might be reconstructed by replaying after the exception (interrupt) arrives. Alternatively, interrupt might be served only after execution reaches the next checkpoint.

overgard 7y ago

I don't understand how you can acknowledge the cpu is literally rewriting your code on the fly by changing the order of operations and making things massively parallel and rewriting things in a proprietary language, while holding the belief that "microcode is really not that different from assembly". At least you can inspect what a C compiler emits to assembly.