David Kanter (dkanter@realworldtech.com) on 7/22/10 wrote:
---------------------------
>I think I understand what you are trying to communicate, but your definition doesn't
>work very well and I'm not sure it's very helpful without further clarification.
>
>As another posted pointed out, reading data without first checking parity is speculative.
>In fact, having a storage element (or combinatorial logic) without parity or ECC
>is speculative. By definition, if data is corrupted, you don't need to read it
>(if there's a separate detection mechanism, for most ECC you need to read to find out if there are errors).

I totally disagree with this. What if the ECC bits are compromised? In other words, there does *not* exist any method which would enable you to tell with *absolute* certainty that the read data is identical to the most recently written data to the same address. All the CPU can do is to resort to pure faith that it will work as expected - there is no magical workaround for this ... and I think you should accept it as one of the most basic facts about our universe.

>So I don't think that definition quite makes sense.

I think it does.

>The problem is that any sort
>of program execution is fundamentally tied to a physical implementation.

I think you don't fully understand what I mean.

As for the confusions about terminology: As far as I can tell, nobody in this forum has suggested a better terminology for describing what I mean.

>For example,
>most CPUs fetch >1 instruction at a time (due to how SRAM is accessed and some degree
>of locality) and that goes hand in hand with pipelining, which generally assumes
>that instruction N+1 is 'close' (in a temporal sense) to instruction N. If you
>have a long enough cycle time, you could fetch 1 instruction a time, let the front
>end calculate any branches and fetch the next instruction.

I am going to handle some of this in a reply to your previous post.

>At that point, you are
>not doing any speculation, but your CPU now has an insanely long cycle time (needs
>to read instruction N, detect a branch, calculate target, fetch instruction N+1).

Yes, but as I already mentioned, I am *not* against speculative-ness. Not against pipelining, not against "probabilistic" caching. What I *am* against is: not having clear concepts about how a real CPU works.

>Moreover, you seem to be defining speculation in terms of 'work' that is not known
>to be needed. That is only interesting because it has an impact on power and performance.
>Isn't leakage a form of work? Leakage is 'work' performed to keep a circuit operating,
>but that circuit might not be needed at all. So it seems to me like this is a case of a definition out of control.
>
>Also, I think your notion of an "OOO CPU without speculation" is kind of specious,
>since OOO is assuming that the code is not written in a dynamically optimal fashion.
>That's a very reasonable assumption, but it's still an assumption.

Well, yes, but nobody is forcing a CPU to start out-of-order execution of an instruction about which it does not know for *sure* it will be executed.

I agree that the "pure OOO without speculation" is not easy to implement in an actual CPU if it has support for exceptions (memory protection fault, division by zero, etc) or interrupts originating in the outside world.