On 02/23/18 12:48, Pankaj Bansal wrote:
>> -----Original Message-----
>> From: Laszlo Ersek [mailto:ler...@redhat.com]
>> Sent: Friday, February 23, 2018 4:52 PM
>> To: Pankaj Bansal <pankaj.ban...@nxp.com>; Udit Kumar
>> <udit.ku...@nxp.com>; Leif Lindholm <leif.lindh...@linaro.org>
>> Cc: michael.d.kin...@intel.com; edk2-devel@lists.01.org;
>> ard.biesheu...@linaro.org; Meenakshi Aggarwal
>> <meenakshi.aggar...@nxp.com>
>> Subject: Re: [edk2] [PATCH edk2-platforms 01/39] Silicon/NXP: Add support
>> for Big Endian Mmio APIs
>>
>> On 02/23/18 12:04, Pankaj Bansal wrote:
>>
>>> However Laszlo, with the method you suggest (using STATIC CONST
>>> UINT16 mOne), would it not add delay in each Mmio Operation ?
>>>
>>> I am concerned about boot delay using this approach.
>> The condition can be evaluated at compile time, so I expect optimizing
>> compilers to eliminate the dead branch.
>>
>> Assuming the condition cannot be eliminated at build time, what is your
>> concern: the single byte access, or the branch instruction?
>>
>> I don't think the single byte access matters. (If you tried to replace that 
>> with a
>> HOB or PCD lookup, it could only be worse.)
>>
>> I also doubt the branch should be a concern. You could replace the "if"
>> (or the ternary operator "?:") with function pointers that you set e.g.
>> in a constructor function. But I think an "if" with an invariable
>> (constant) controlling expression is at least as friendly towards branch
>> predictors as a function pointer variable (through which you might be
>> *forced* to make a real function call).
>>
>> Personally I wouldn't worry.
>>
> 
> I think you are right about smart compiler eliminating the branches at build 
> time.
> I just pointed this out because we call Mmio/BeMmio APIs when accessing Nor 
> flash for variable read/write.
> As these are called so many time during boot, I did not want any delay to be 
> added to these APIs than necessary.
> Now that you have pointed it out, I don't think any significant delay will be 
> added to these APIs.

In addition to that, physical flash access is likely so slow anyway that
a few additional instructions should be lost in the noise, generally
speaking.

Thanks
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

Reply via email to