There are really two issues here, I think:

1. Managing the ordering of the two micro-ops in the pipeline, which seems
to be the issue you're facing.
2. Providing atomicity when you have multiple cores.

I'm surprised you're having problems with #1, because that's the easy part.
I'd assume that you'd have a direct data dependency between the micro-ops
(the load would write a register that the store reads, for the load to pass
data to the store) which should enforce ordering.  In addition, since
they're both accessing the same memory location, there shouldn't be any
reordering of the memory operations either.

Providing atomicity in the memory system is the harder part. The x86 atomic
RMW memory ops are implemented by setting LOCKED_RMW on both the load and
store operations (see
http://grok.gem5.org/source/xref/gem5/src/mem/request.hh#145, as well
as src/arch/x86/isa/microops/ldstop.isa). This works with AtomicSimpleCPU
and with Ruby, but there is no support for enforcing this atomicity in the
classic cache in timing mode.  I have a patch that provides this but you
have to apply it manually: http://reviews.gem5.org/r/2691.

Steve



On Wed, Jul 27, 2016 at 9:10 AM Alec Roelke <[email protected]> wrote:

> Hello,
>
> I'm trying to add an ISA to gem5 which has several atomic
> read-modify-write instructions.  Currently I have them implemented as pairs
> of micro-ops which read data in the first operation and then modify-write
> in the second.  This works for the simple CPU model, but runs into trouble
> for the minor and O3 models, which want to execute the modify-write half
> before the load half is complete.  I tried forcing both parts of the
> instruction to have the same src and dest register indices, but that causes
> other problems with the O3 model.
>
> Is there a way to indicate that there is a data dependency between the two
> micro-ops in the instruction?  Or, better yet, is there a way I could
> somehow have two memory accesses in one instruction without having to split
> it into micro-ops?
>
> Thanks,
> Alec Roelke
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to