yy2bggggs
Master Poster
- Joined
- Oct 22, 2007
- Messages
- 2,435
Your example program was also unduly complicated to go through in a forum discussion, so let me fix that.But the remark was the context of a specific example.
In my example Run1 and Run2 are runs of the algorithm normally on a computer.
Let's focus on two instructions: X and Y. X will involve a store to a piece of memory. Y involves a fetch from that location. No store instructions exist in between.
To give the processor something to do, let's have three registers--R1, R2, and R3. X stores R3 at memory location R1+R2. Y fetches what is at memory location R1 and stores it into R2. To illustrate something coherent going on, we'll have Y fetch what X stored. More precisely, X precedes Y, and there are no stores to the specified memory address between X and Y. Arbitrarily, I'm also going to say there are a few instructions between X and Y.
Let's also suppose this is a straightforward case, where our expected side effects are considered to be complete by the execution of the next instruction. In other words, if we do a fetch at step k into some register r, register r has the expected value at step k+1.
So let's say at X, R1 is 10, R2 is 30, and R3 is 12. So the program is supposed to store the value 12 at address 40. At Y, R1 is 40, so it's supposed to fetch what is at address 40 and store it into R2. By definition of memory on an imperative machine, R2 would be 12.
For Run2, the same thing. Only we're storing the state of all of the registers.
Now for Run3...
Between steps X-1 and X, something was put into the registers. By step X, R1 is 10, R2 is 30, and R3 is 12. The processor adds 10 to 30 and gets 40, so it takes 12 and performs a write to address 40. It turns on all of the lines, enables the bus, whatever--and 12 is supposed to go in. It does.
Then between X and X+1, everything is erased. Fine. But the registers are loaded, the opcode fetched, and everything put in, and the processor is in a particular state--the same state, mind you, that it was in for X+1 at Runs 1 and 2.
Now just prior to step Y, everything is erased, and then a fetch is performed from this cache. R1 gets the value of 40 at this fetch. At step Y, the machine is supposed to retrieve what is at memory location 40, and store it in R2. So it performs this operation. It turns the lines on, enables the bus for a read, and so forth. The value 0 dutifully flows in. So now R2 has 0 in it... assuming there's enough time to settle. And we proceed to step Y+1.
But before doing so, there's that fetch from the cache. That fetch takes R2 and puts the value 12 into it. It loads in the opcode it's supposed to load in. And now we're at step Y+1, and we're, by definition of your problem, in the same state as Run2 (and Run1) was in Y+1, within the processor.
It appears to me, that if you look at memory in terms of a black box that gives you certain guarantees, which have to be met in order to proceed through the algorithm, and take a processor's eye view, then in Run1, Run2, and Run3, the black box is performing its required duties, so the processor is not crippled in its duties.
And nothing I said here is incorrect, nor should it be controversial. Agree?
Disagree. I agree that Run3 is different than Run2. You defined it differently. But I disagree that you are saying why it's different. Here's why. Here is what you are saying:So I am saying why is this run different from the last.
However, the phrase I have highlighted above is true for:Rocketdodger and PixyMisa are saying that it is because the algorithm is self-referential or it can inspect itself or something and therefore the third physically identical run will behave differently.
I am saying, no, all that CPU sees when it processes an instruction is the register state, the instruction itself and the data item's it is asked to process.
- Run1 at X-1
- Run1 at X
- Run1 at X+1
- Run1 at Y-1
- Run1 at Y
- Run1 at Y+1
- Run2 at X-1
- Run2 at X
- Run2 at X+1
- Run2 at Y-1
- Run2 at Y
- Run2 at Y+1
- Run3 at X-1
- Run3 at X
- Run3 at X+1
- Run3 at Y-1
- Run3 at Y
- Run3 at Y+1
Now, given that your highlighted phrase is true for all of the above, I'm having problems finding out where this difference is that you're trying to point out.
That's what we in the business call "the same".It has no way of knowing or caring where that data item came from. That is what I mean by in isolation.
Yep.So the changed data are ditched after each operation, and the cached data from the previous run is swapped in, which will of course be the same.
Yep.So the next instruction comes along and duly processes it, just the same as if it had read from the memory item or register it had changed in the last step.
Now the above sentence is so muddled and confused I can hardly make sense out of it.Now you are chiming in and agreeing with PixyMisa and rocketdodger that this processor cycle is not in isolation from the rest of the steps in the program - that something will be different in this physically identical set of instructions.
Part 1, before the dash:
The processor cycle, let's say, is step Y. X is one of the rest of the steps. Y isn't in total isolation of X. What happens at Y should depend on X. If it doesn't, that means that memory is failing to supply its black box guarantees that we rely on in order to run the algorithm.
And yes, that is what I'm claiming.
Part 2, after the dash:
The set of instructions is the entire Run1. I don't know what you mean by "something". But saying that Y isn't isolated from X says absolutely nothing about Run3 being different than Run1.
Furthermore, I thought you said you were showing what the difference is.
But regardless, part 2 being completely different than part 1, and this "showing a difference" thing somehow mutating within your post into "same thing", and "set" being the same as "cycle", etc... I cannot make a lick of sense out of the aforementioned quoted text. Could you please help?
Last edited: