I looked at it, and I think #2 is the way to go, ie change the microops
and not the way they're instantiated.
Gabe
On 10/27/11 23:30, Gabe Black wrote:
> 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
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
