It's been a while so I don't remember what the code is doing off hand.
Give me a chance to look at it this weekend. If you're asking why the
instruction flags and the memory flags are independent, one goes into
the instruction object itself and one goes into the request object when
the access is generated. If you're asking why the mechanism that handles
them is different, I'd have to look at the specifics to say. I'd guess
either it's always been that way, or the were the same once and one (I
think the instruction flags) was changed.
If there's a locked flag and for x86 that also means the instruction has
to be a memory barrier, there probably doesn't need to be a second
option. The first should just imply that the the locked flag should be
applied to the request and the memory barrier flag should be applied to
the instruction.
Gabe
On 10/27/11 17:48, Nilay Vaish wrote:
> Now I have been able to make some progress on the ISA parser. As per
> my understanding there are two ways to mark ldstl and stul as
> non-speculative and memory barriers.
>
> 1. Change the definition in of LdSt and BigLdSt in
> src/arch/x86/isa/microops/ldstop.isa so that they take memBar as a
> flag as well. Similarly, we change the definition of StoreOp and
> LoadOp (they appear in the same file) so that memBar is passed on to
> the super class's constructor. Then, in each of the python files that
> make use of ldstl and stul, we can add the flags nonSpec and memBar
> with values True.
>
> 2. Change LdSt and BigLdSt as stated in 1. Make changes to
> defineMicro{Store/Load}Op definitions so that they take memBar as an
> argument and passes it on to the super class' constructor. Change the
> definitions of all the microops accordingly. In this case, I think the
> python files do not change. But it may mean that we can not change the
> microop's flags in different macroops.
>
> If this sounds Greek, I am ready to post patches for these two.
>
> Gabe, what do you say?
> One more thing, why did you choose to treat memory flags and
> instruction flags in different manner in ldstop.isa?
>
> --
> Nilay
>
>
> On Thu, 27 Oct 2011, Nilay Vaish wrote:
>
>> On Thu, 27 Oct 2011, Steve Reinhardt wrote:
>>
>>> Hi Nilay,
>>>
>>> I think a memory barrier may not be sufficient... we need to make
>>> sure it's
>>> non-speculative as well as ordered (unless we do something more
>>> complicated
>>> to deal with a speculative locked read that isn't followed by a write
>>> because it got squashed).
>>
>> I could not find anything in AMD's manual on locked instruction being
>> executed non-speculatively. In one of the Intel manuals, it was
>> stated that read portion is never is issued unless it is ensured that
>> write portion will also be issued. So that means that we also need
>> mark the instruction as non-speculative, apart from marking it as a
>> memory barrier.
>>
>>>
>>> Gabe is a better reference (the only reference?) for the details of
>>> the x86
>>> decoder.
>>
>> That does not sound good.
>>
>>>
>>> Steve
>>>
>>> On Thu, Oct 27, 2011 at 8:32 AM, Nilay Vaish <[email protected]> wrote:
>>>
>>>> I am thinking of marking all the locked instructions with
>>>> IsMemBarrier.
>>>> Where do you think this flag should appear - in locked_opcodes.isa,
>>>> or in
>>>> semaphores.py? I tried adding IsMemBarrier to the instructions in
>>>> locked_opcodes.isa, but that does not work. I changed the
>>>> instruction format
>>>> to BasicOperate, that also does not work.
> _______________________________________________
> gem5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/gem5-dev
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
