On 02/23/18 12:48, Pankaj Bansal wrote: >> -----Original Message----- >> From: Laszlo Ersek [mailto:[email protected]] >> Sent: Friday, February 23, 2018 4:52 PM >> To: Pankaj Bansal <[email protected]>; Udit Kumar >> <[email protected]>; Leif Lindholm <[email protected]> >> Cc: [email protected]; [email protected]; >> [email protected]; Meenakshi Aggarwal >> <[email protected]> >> 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 [email protected] https://lists.01.org/mailman/listinfo/edk2-devel
