On Sat, Feb 20, 2016 at 3:28 AM, Peter Maydell <peter.mayd...@linaro.org> wrote:
> On 19 February 2016 at 19:38, Alistair Francis <alistai...@gmail.com> wrote:
>> On Fri, Feb 19, 2016 at 6:39 AM, Peter Maydell <peter.mayd...@linaro.org>
>> wrote:
>>> +/* Check for traps to performance monitor registers, which are controlled
>>> + * by MDCR_EL2.TPM for EL2 and MDCR_EL3.TPM for EL3.
>>> + */
>>> +static CPAccessResult access_tpm(CPUARMState *env, const ARMCPRegInfo *ri,
>>> + bool isread)
>>> +{
>>> + int el = arm_current_el(env);
>>> +
>>> + if (el < 2 && (env->cp15.mdcr_el2 & MDCR_TPM)
>>> + && !arm_is_secure_below_el3(env)) {
>>> + return CP_ACCESS_TRAP_EL2;
>>> + }
>>> + if (el < 3 && (env->cp15.mdcr_el3 & MDCR_TPM)) {
>>> + return CP_ACCESS_TRAP_EL3;
>>> + }
>>
>> Hey Peter,
>>
>> Why not use else if?
>
> I generally tend not to use else-if ladders if the thing
> in the conditional returns unconditionally, just as a
> personal style preference. "if () { X } else if () { Y } Z"
> implies a possible control flow path of "take the if
> branch so run X, then skip Y, and continue after to run Z",
> and if X returns unconditionally that can't happen.
> It also matches up with the usual approach of
> if (something) {
> early return;
> }
> main body of function;
>
> which you wouldn't want to write as
> if (something) {
> early return;
> } else {
> main body;
> }
Fair point. I always thought of it the other way around. If you can't
go into the other branches then it should be if () { return } else if
() { return } to make it more explict.
It doesn't matter though.
Acked-by: Alistair Francis <alistair.fran...@xilinx.com>
Thanks,
Alistair
>
> thanks
> -- PMM
