> Now that you know what I'm talking about, You don't know what you're talking about. I worked on CPU design teams for 8 years of my professional career. I'm

> Now that you know what I'm talking about, You don't know what you're talking about. I worked on CPU design teams for 8 years of my professional career. I'm telling you how they're actually built and don't need to use phrases like "CPU takes its steps" as if that's meaningful. Your conceptions about how CPUs are designed, how the design team actually reasons about what they're building, is wrong. It is not correct. You have no evidence this is actually how those people think. > if you still insist on your point, and if you'd like to help me understand how I'm wrong, which I would appreciate, could you please show me how that live diagram would look like for a C program and its state, since as you say, C programs with its variables and the CPU with its registers are the same kind of "stateful". I wouldn't venture near such a misguided statement. The closest I'd come would be something along the lines of "At the sequence points of a C program, parallels could be drawn to specific structures in the CPU responsible for tracking that state." Note that those are meaningful words that someone could describe as "wrong" with an explanation, not groping in the dark for "stateful" to be stretched to cover both cases or whatever you were accusing me of doing/not doing. But even then, the entire state of a C program at a sequence point might not co-exist temporally inside a CPU that nevertheless returns a correct result so it would take some more guard language. > There's a set number of registers and it never changes throughout execution. This is a prime example where it's really clear you haven't considered a CPU architecture from the last decade or so. There are a set number of architectural registers. Inside the actual chip, because we're considering a window of 40 uops instead of one macroinstruction at a time there are an indefinite number of dynamically assigned registers that may potentially hold the value of one architectural register. Look up "Register Renaming" for yet another tables stakes CPU arch concept you're blissfully unaware of. This is probably going to keep happening. You really don't know enough about the subject matter to make correct or wrong statements. As is, your statement isn't precise enough to know if you were wrong about physical registers or right about abstracted architectural registers. Note that being "right" about architectural registers means your argument is based on an abstraction instead of implementation. And you really wanted to be talking about implementation. > Please stop trying to talk about assembly. I know assembly. I've programmed Win32 assembly (you can make fun of me, it's fine). I'm not talking about assembly here. I'm talking about the CPU designers or programmers and the guarantees they have when programming that we rarely do in HLLs. I mentioned assembly once, in passing as a durable layer of abstraction. I also mentioned a whole host of physical reasons why your input/output determinism is false, all of which are equally as devastating to your argument as the one comment you've zeroed in on for no particular reason. I'd appreciate at least acknowledging that something as finicky as a PLL probably has to be included in a discussion about modern CPU's. Were you going to address any of that or pretend it didn't happen? > Think of this another way: say you are designing/coding a CPU. Isn't every possible error that can happen your fault? Is that the case in C? Whose fault is it if the computer runs out of memory? If memory gets corrupted? If a hacker pokes your memory to cheat in a game? It's no one's fault, those things can't be predicted. But when designing a CPU you can be sure you have the power to predict every possible thing that can happen in your problem domain. Because you're designing a dataflow grid and an adjunct list of booleans whose semantics are immaterial to you. But in C it's just not possible (nor in any other language, C is just a stand-in here) because you are invested in the semantics. You're not holding yourself to precise enough language for this discussion. First of all, in this low level of a discussion using "fault" in the sense of assigning blame introduces needless ambiguity. I would phrase the "hacker poking" example as "if a ring3 process can have write access to" and it approaches something precise enough to be wrong. All of your examples are detailed in the specification for (most?) architectures, so it would be pretty clear if a simulator and a piece of silicon disagreed who was incorrect. The CPU designers are NOT "sure [they] have the power to predict every possible thing that can happen in [their] problem domain." They're smart enough to know that the space of x86 programs isn't possible to reduce to formalism. Random testing, directed random testing, and a lot of other strategies are in constant use that would not be if that power actually existed. I explicitly brought this up before as being wrong, nice to see you're not even giving me a fair read before charging ahead with your fantasy. Nobody currently designing CPU's reasons about it as a "dataflow grid and an adjunct list of booleans." This is a complete fabrication on your part. If you have anything from any current CPU architect, designer, or engineer that actually uses this verbiage to describe what's going on I would appreciate a link or two. So far it looks like you've invented it and are willing to push for this broken metaphor instead of admit there might be something you don't know. If none of this sinks in, consider that CPU's are written in Verilog. Take the Cantor-diagonal proof of C being insufficient to compute all irrationals and feed Verilog into it. Share your answer with the rest of the class.