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; email@example.com;
>> ard.biesheu...@linaro.org; Meenakshi Aggarwal
>> 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
> 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
edk2-devel mailing list