anon (anon@anon.com) on 7/21/10 wrote:
---------------------------
>? (0xe2.0x9a.0x9b@gmail.com) on 7/21/10 wrote:
>---------------------------
>>slacker (s@lack.er) on 7/20/10 wrote:
>>---------------------------
>>The term "branch prediction" seems too constrained for me in this context. To generalize,
>>it is about the assumptions a pipelined CPU makes about the address of the next
>>instruction to be executed. Those assumptions can go wrong in pathological cases.
>>And these assumptions are present there even if the code contains *no* branch instructions
>>at all. Technically, a CPU does not need any branch instructions in order to be
>>a universal Turing machine, it only needs instructions for writing to memory from
>>which the CPU reads the code. A jump instruction is in fact a highly specialized memory write instruction.
>>
>>It is pure speculation for an x86 CPU to think that "if the address of the current
>>(non-branch) memory write instruction is ADDR, then the address of the next instruction
>>will be ADDR+1".
>
>I think I can see what you are getting at, but you are wrong too. The address of
>the next instruction definitely will be ADDR+1, but its contents may change.

Yes, I meant the contents of the address ADDR+1. The correct sentence should have been that pipelining makes the assumption: "If ADDR contains a memory write instruction I0 and ADDR+1 contains the value I1, then the instruction executed after I0 will be I1".

>But you're wrong about this as an example of how pipelining requires speculation
>because CPUs disallow such sequences without cache and pipeline draining instructions.

There are two options of how to design a pipelined version of a CPU:

1. Maintain full compatibility between the pipelined and non-pipelined versions, even for all the unlikely corner-cases such as intense self-modifying code. The two CPUs give mathematically identical results in all possible cases.

2. Do not maintain full compatibility. One specimen of this approach are the transitions from 8086 to 286 to 386 to 486 etc.

I was mainly talking about case (1).

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.

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

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