[Newcompiler] Re: NewCompiler-ms.273.mcz

[Klaus D. Witzel]

Hi Math,

on Sat, 08 Sep 2007 11:43:31 +0200, you wrote:

> Hi Klaus
>
> On Sep 8, 2007, at 9:12 AM, Klaus D. Witzel wrote:
>
>>> - Add a more powerfull way for comparing compiled method
>> ...
>>>
>>> Article:
>>> * http://www.squeaksource.com/NewCompiler.html
>>>
>>> Download:
>>> * http://www.squeaksource.com/NewCompiler/NewCompiler-ms.273.mcz
>>
>> Hi Math,
>>
>> the same primitive can be used by many methods but with different  
>> fallback code (in case the primitive fails). This so can make two  
>> methods unequal. I'd suggest to eliminate the check for
>>
>> (self primitive > 0 and: [self primitive = method primitive])
>> 		ifTrue:[^true].
>
> I know but the decompiler seems to produce different method for quick  
> return.
> It must be fix but it will not really change so I change it to:
>
> "Dont bother checking quick return"
> 	(self isReturnSpecial and: [self primitive = method primitive])
> 		ifTrue:[^true].

Even better so :)

>
>>
>> Now since comparision of primitive numbers was formerly subsummed by
>>
>> self header = method header ifFalse: [^false].
>
> Yes but the decompiler, some time added a temporary variable but the  
> method is the same.
>
>>
>> , I'd suggest to put primitive number comparision back as
>>
>>  self primitive = method primitive
>> 		ifFalse: [^false].
>
> added.

OK

>>
>> Also,
>>
>>  self initialPC to: self endPC do:
>>
>> was formerly guarded by
>>
>>  self size = method size ifFalse: [^false].
>>
>> Without such a guard, it's not impossible that you compare elements  
>> which are not bytecode.
>
> Yes some bytecode is the same but depending on the offset of the  
> temporary the bycode use the extend bytecode and size is different but  
> method are the same.
>
> The decompiler change the order of the temporary that is why it can  
> happen.
>
> So I have added:
>
> self size = method size ifFalse: [^(InstructionCompaire compaire: self  
> with: method)].

Good one :) gives more independence to the decompiler maintainer (bytecode  
instruction v.s. deepest possible message level instruction :)

>>
>> Last but not least: comparing the literals must parallel the way the  
>> compiler compares the literals, see call sites of #addLiteral:, i.e.  
>> #pushLiteral: in BytecodeGenerator. With other words, not using #= for  
>> literal comparision but instead use #literalEqual:.
>
> I remove the literal comparison since my InstructionCompaire dose it  
> implicitly.
> but #literalEqual: dose the same than #=:
>
> Object>>literalEqual: other
>
> 	^ self class == other class and: [self = other]

I know, I was also puzzled at the time when I made more BytecodeGenerator  
methods use #literalEqual: but I agree with the initial author, since that  
is the best place where people can override independent of #= (and I think  
that a candidate for such override will be Float, partly because of  
Float>>#nan ;-)

>
>>
>> For the case of float literal comparision (which should be done by  
>> Float itself in its override of #literalEqual:) I'd suggest to ask the  
>> Squeak community about their opinion, their use cases and their  
>> numerical tolerance.
>>
>> As always, I'm open to critique :)
>
> Thanks :) It is a pleasure to read your remarks.
> Tell me if you are not agree with my changes.

All agreed :)

I can post the Float>>#= v.s. #literalEqual: question to squeak-dev if you  
want me.

Cheers
Klaus

>>
>> /Klaus
>
>
> 	
>
> 	
> 		
> ___________________________________________________________________________ 
> Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son  
> interface révolutionnaire.
> http://fr.mail.yahoo.com