>From a historical perspective, highly pipelined x86 CPUs >appeared after the non-pipelined
>ones.
> The idea you are advocating here is in contradiction >with this, because the
>instruction set of the older CPUs had (=past) no idea about pipelining. Of course,
>now (=present) that we can see "the bigger picture", anyone going to design a non-pipelined
>CPU will be wise to add some pipeline-management instructions to the instruction
>set, just in case if there will be a pipelined version. >But in case of old CPU designs
>and old codes, you cannot travel back in time to 1970-ties.
>
>>Exceptions are another one, but again it could have imprecise exceptions and not require speculative execution.
>
>Well, but you cannot go back to 1970 and fix 8086 so that >it knows about the concept of imprecise exceptions.

What pipeline management instructions would you want?

>>> Writes to registers are OK from this point of view, since the CPU
>>>never fetches an instruction from there. In CPUs which are able to do data speculation,
>>>even writing a register might cause partial pipeline stalls. (I don't know why I
>>>am writing this here, because it seems obvious.)
>>>
>>>If you think pipelining in a universal-computation CPU has nothing to do with speculation,
>>>you are simply wrong.
>>
>>On the contrary, I think your assertion that pipelining requires speculative execution is wrong.
>
>I am not saying that. I am saying this: Pipelining, the way it is implemented in
>current CPUs (e.g: Core2), involves certain assumptions about what patterns will
>there be when the code is actually executed. Those assumptions are made without
>any prior attempts to check whether the code actually matches those patterns. The
>conversation between the CPU and the code looks like:
>
>Code: Hi there, CPU, my friend. I want you to execute me.
>
>CPU: No problem. Hand me the first couple of your instructions.
>
>Code: Only a couple of them? You mean you don't want to see all of them?
>
>CPU: That's right.
>
>Code: But but, then, you aren't going to know what I am going to do.
>
>CPU: Don't worry. I will manage.
>
>Code: How?
>
>CPU: Look pal, I know your kind. You will tell me to execute a bunch of moderately
>long sequences of adjacent instructions. Plus some branches here and there.
>
>Code: Maybe, but what if you are wrong about me? Your assumptions seem to me like
>some kind of speculation about my nature.
>
>CPU: Don't be so shy and hand me the initial couple of instructions!
>
>Code: What if I don't ...
>
>CPU: You don't have a choice ...

OK - that was pretty funny : )

I'd say the assumptions though are much looser (typically you assume no more than one branch/cycle and roughly 2-3 instructions per branch).

That being said, what would you think of as an alternative?

There's no way that the CPU can examine all the instruction in a program (and you probably wouldn't want to either, since many static instructions are not executed dynamically).

And even the program itself may not have a good idea of what is going on (e.g. dynamic linking to libraries).

>>> On the other hand, non-speculative pipelining *is* possible,
>>>but only if the CPU is able to mathematically prove that a particular piece of code
>>>is never violating any assumptions made by the pipelined architecture. But how many
>>>existing CPUs are able to do such proofs?
>>
>>Anecdotal evidence does not make your claim correct.
>>
>>>Similarly, L1/L2 caches without any traces of speculative-ness whatsoever are also
>>>possible - provided the CPU is able to actually prove that the memory access patterns
>>>in a particular piece of code are fully known in advance. But how many existing
>>>CPUs are able to do such proofs? (Considering the design of the x86 ISA, I cannot
>>say I blame them for this inability.)
>>
>>Caches have nothing to do with speculative execution that you were talking about.
>
>What are you saying? That if a contemporary CPU (Core2 or >whatever) decides to
>allocate a cache-line for data at address 0x1230, it is >not making any speculations
>about future uses of that piece of data?
>
>(Note: I am *not* against caches)

I agree that caches definitely are speculative optimizations. Rather helpful ones.

David