[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [f-cpu] Conditionnal load and store, the return
> > > > I have reread the discussion about conditionnal load and store, and I
> > > > think that we forgot something : exception. In fact when we do a load
> > > > or a store and check the condition only on write.
> > In fact we were speaking about a possible store[z/nz/m/l/nm/nl] and
> > load[z/nz/m/l/nm/nl] instructions. And the problem was that currently the
> > test is checked on wright, that mean you do first load the data and then
> > you verify if the test is ok.
>
> load the data ? what data ? the conditional load only to need access
> to memory if condition is true, so even an exception occurs, when
> reexecuting the faulty instruction, all is okay. Same thing for the
> conditional store.
> So i don't see any problem.
You will not reexecute it. I mean the conditionnal store on wich we
discuss test if the condition register is zero or not, or if the lsb/msb
if zero or not and if the test is true, the write is done. If you load
a data conditionnaly, if the address isn't ok, and the test is false, no
exeption must occur and it's where the problem is.
> I maybe miss something.
I think that you are thinking to the specific form that test if any access
occur since you have read the data. That's the problem I speak on at the end
of this mail.
> The problem is that if you access to a not valid
>
> > But in fact we still have a problem with the conditional store/load
> > with the LSU test in multi processor architecture.
> Again, I don't see any problem.
Currently if you have this :
[DATA]
|
[CPU 1]---[CPU 2]
When CPU2 do a conditional load/Store pair, it will not be abble to see
if CPU 1 access to the data. The only reason why CPU 2 know that, is because
all memory access will always be send to CPU 2 by CPU 1... It can be a
big overkill. I perhaps miss something but the problem exist.
Cedric
*************************************************************
To unsubscribe, send an e-mail to majordomo@seul.org with
unsubscribe f-cpu in the body. http://f-cpu.seul.org/