On Wed, Sep 15, 2021 at 9:16 AM Giovanni Mascellani gmascellani@codeweavers.com wrote:
Hi,
Il 10/09/21 01:16, Matteo Bruni ha scritto:
As far as I'm aware, booleans in SM4+ are represented in quite a peculiar way: false is represented as 0, true is canonically 0xffffffff. I think the idea is to be able to use the result of a conditional expression directly as a mask and such, but don't quote me on that. For sure it's different from SM1-3, which use the traditional 0 and 1 values for false and true.
Well, isn't it our choice how we decide to represent things internally? The only important requirement is that casts (and everything else) have the correct semantics. Whether inside a true bool variable there is 1, ~0u or whatever else it's our decision. If we store 1 for true, then we have to use MOVC (or a comparison followed by INEG) when casting to bool and MOV or ITOF when casting to int or float. If we store ~0, then we use a simple comparison for casting to bool and MOVC (or INEG and possibly ITOF) to cast to int or float.
In case we want to be closer to native (though I'm not sure it's really a requirement in this case: I expect all this opcodes to be well supported everywhere), then probably choosing to represent true as ~0u is better, but it's just a matter of choice. The really important thing is to be aware and consistent with the choice.
So what do we decide? I already have patches that implements comparison operators that assume that true is represented as 1. I can fix them, but please tell me what do we want.
Giovanni.
Yeah, we do want to have true as ~0u for SM4+ (there is no real bool type in < SM4, so that doesn't matter). There is no reason to do things differently and there might be some other unexpected way for the internal representation of true to leak in a visible manner.