int opEquals(Object), and other legacy ints

[Stewart Gordon]

Walter Bright wrote:
> 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?

If anything resembling the above, then

     return this.bar-foo.bar?0:1;

which cancels out the advantage you mention next:

<snip>
> 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.

<snip>
>> 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.

How is this (a == b) rather than (a != b)?

Stewart.

-- 
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/M d- s:-@ C++@ a->--- UB@ P+ L E@ W++@ N+++ o K-@ w++@ O? M V? PS- 
PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y
------END GEEK CODE BLOCK------

My e-mail is valid but not my primary mailbox.  Please keep replies on 
the 'group where everyone may benefit.