No, the effort isn't the issue, it's the condition the code would be
in after the change. If the code was already like what Nilay is
proposing, I would spend the effort to change it to be like what I'm
proposing.
Gabe
Quoting "Beckmann, Brad" <[email protected]>:
Thanks Gabe and Nilay for restarting this conversation.
So I don't understand all the issues here, but it seems like Gabe's
concern is the effort required to support Nilay's proposal, correct?
If so, then if Nilay is willing to make all required changes to
support his proposal, would that be ok?
Brad
-----Original Message-----
From: [email protected] [mailto:gem5-dev-
[email protected]] On Behalf Of Gabriel Michael Black
Sent: Tuesday, May 15, 2012 8:29 PM
To: [email protected]
Subject: Re: [gem5-dev] Review Request: X86: Split Condition Code register
The call sight isn't wildly different, except that setCCFlagsBits
will have fewer
parameters and won't have to put some of them on the stack.
A lot of the complexity comes from breaking up setCCFlagsBits so that you
have lots of function signatures, curly brackets, return lines,
etc., and some
functions which duplicate logic operating on the emulation or non-emulation
version of a flag.
Gabe
Quoting Nilay Vaish <[email protected]>:
> What I proposed --
>
> zaps = setZaps(zaps,ext);
> ecf = setEcf(ecf,ext);
>
> What I believe Gabe proposed --
>
> temp = setCCFlagsBits(zaps|ecf,ext);
> zaps = temp & zapsmask
> ecf = temp & ecfmask;
>
> As of now I don't seen any merit that the second approach has over the
> first one. Gabe, would you explain why do you want to go with the
> second one?
>
> --
> Nilay
>
>
> On Fri, 11 May 2012, Gabe Black wrote:
>
>> We're debating how the code in the patch should be organized. My
>> position is still that the function which computes condition codes
>> should not be split up and doesn't actually need to change. It sounds
>> like Steve agrees.
>>
>> Gabe
>>
>> On 05/10/12 13:31, Beckmann, Brad wrote:
>>> What is the status of this patch? Nilay, are you trying to address
>>> Gabe's concerns or are you having a problem defining a solution that
>>> meets both your and Gabe's requirements? I don't understand the
>>> specifics of this patch, but I want to do whatever possible to find
>>> a solution. This is a critical fix for the O3
>>> x86 CPU model.
>>>
>>> Thanks,
>>>
>>> Brad
> _______________________________________________
> 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
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
