I don't think that's true, but I may be confused. I think, at least
for the timing CPU, that it checks if a read/write was called and
doesn't just fall through. The timing CPU would wait forever for a
read/write response that would never come otherwise. (digs around a
little) I think it's sort of like what I described. The CPU will
continue if it's not waiting for anything, which would be the case if
no access actually happened. We could probably get the same behavior
if we checked if the instruction was waiting for a read/write
response, but that might be kept somewhere annoying to get at.
Generally, if we can hide the existence of predication from the CPUs,
I think that'll make everyones life easier (except for the ARM ISA's,
I suppose).
Gabe
Quoting Ali Saidi <[email protected]>:
It's not the same issue here. The simple cpus just have their
execute/completeAccess methods guarded by a predicate condition test. If
nothing happens in there, so be it and the cpu goes onto the next
instruction without complaint. The out of order cpu on the other hand
needs to know if the instruction was predicated false so it can notify
commit that it is complete, even though it hasn't done anything. If commit
isn't notified, the instruction will never commit and the processor will
stall.
This information should clearly belong in the dyninst. Unless there is
some other way to access the class from the the isa description, I think
the change is correct. An alternate approach would be to have the method in
threadstate do nothing because it's unimportant for it.
Ali
On Tue, 17 Aug 2010 19:04:10 -0400, Gabriel Michael Black
<[email protected]> wrote:
Sorry if I wasn't clear before (I reread my post and it sounded a
little vague) but what the simple CPU does is keep track of whether
the supposed memory instruction actually calls read or write on the
execution context. If not, then the CPU doesn't try to complete any
access, it just considers that part over. Ideally we can do the same
thing here.
Gabe
Quoting Ali Saidi <[email protected]>:
Anyone have comments on this? It seems like this is the only way to
access
the DynInst from the isa description. Threadstate does have the current
instruction in it, as well as things like "Temporary storage to pass
the
source address from copy_load to". It doesn't seem to out of place to
include current instruction predication state in there.
Ali
On Sat, 14 Aug 2010 07:08:35 -0000, "Gabe Black"
<[email protected]>
wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/177/#review185
-----------------------------------------------------------
src/cpu/thread_context.hh
<http://reviews.m5sim.org/r/177/#comment326>
This isn't really a property of a thread, it's the property of a
single instruction. I don't think this is being done in the right
place. I think we should have a discussion on m5-dev to determine
the
best way to handle this. There was a little code added to the
simple
CPU that does what this is supposed to do if a memory instruction
didn't actually read or write memory, and I think this is a better
way
to handle this. We should have a discussion about this on m5-dev,
especially since it touches lots of low level bits like *contexts,
instruction behavior, CPUs, etc. These sorts of changes need to be
made
carefully.
- Gabe
On 2010-08-13 10:12:35, Ali Saidi wrote:
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/177/
-----------------------------------------------------------
(Updated 2010-08-13 10:12:35)
Review request for Default and Min Kyu Jeong.
Summary
-------
ARM/O3: store the result of the predicate evaluation in DynInst or
Threadstate.
THis allows the CPU to handle predicated-false instructions
accordingly.
This particular patch makes loads that are predicated-false to be
sent
straight to the commit stage directly, not waiting for return of the
data
that was never requested since it was predicated-false.
Diffs
-----
src/arch/arm/isa/templates/mem.isa 3c48b2b3cb83
src/arch/arm/isa/templates/pred.isa 3c48b2b3cb83
src/cpu/base_dyn_inst.hh 3c48b2b3cb83
src/cpu/base_dyn_inst_impl.hh 3c48b2b3cb83
src/cpu/o3/lsq_unit_impl.hh 3c48b2b3cb83
src/cpu/simple/base.hh 3c48b2b3cb83
src/cpu/simple_thread.hh 3c48b2b3cb83
src/cpu/thread_context.hh 3c48b2b3cb83
Diff: http://reviews.m5sim.org/r/177/diff
Testing
-------
Thanks,
Ali
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev
