int opEquals(Object), and other legacy ints

[Walter Bright]

Stewart Gordon wrote:
> xs0 wrote:
> <snip>
>> Well, I'm just guessing, but I think something like
>>
>>  > int opEquals(Foo foo)
>>  > {
>>  >     return this.bar == foo.bar;
>>  > }
>>
>> is compiled to something like
>>
>>> return this.bar-foo.bar; // 1 instruction
>>
>> but if the return type is bool, it becomes
>>
>>> return this.bar-foo.bar?1:0; // 3 instructions
> 
> If it does this, then there's a serious bug in the compiler.

What instruction sequence do expect to be generated for it?

> Moreover, what's your evidence that subtracting one number from another 
> might be more efficient than comparing them for equality directly?

The only difference between a CMP and a SUB instruction is where the 
result ends up. But the CMP doesn't generate 0 or 1 as a result, it puts 
the result in the FLAGS register. Converting the FLAGS to a 0 or 1 in a 
register takes more instructions.

>> It's the 1/0 constraint on bools that causes the slowness, not the 
>> size (stack is usually size_t-aligned anyway)
> 
> But if the function only tries to return 0 or 1 anyway, then what 
> difference does it make?  At the moment, I can't think of an example of 
> equality testing that can be made more efficient by being allowed to 
> return a value other than 0 or 1.

I can. (a == b), where a and b are ints, can be implemented as (a - b), 
and the result is int 0 for equality, int !=0 for inequality.