It was just a wild guess, because I did not look at the code nor any other
detail.
If you already analyzed it, I trust you, you are more advanced than me on
the subject :)
Fixing the Decompiler might be a bit more involved the way it is written
now...
But with your fast progress and fearless diving in lower level details, I
think you can do it :)

Le sam. 22 févr. 2020 à 18:44, Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> a écrit :

> Hi Nicolas,
>
>
> > could it be for the case when there is no otherwise?
>
> In this case, a "self caseError" will be generated (though this is no
> correct behavior either IMO, see Problems with #caseError
> <http://forum.world.st/Problems-with-caseError-tp5111930p5112255.html>).
> I don't see how this should affect the jumps or returns before the
> otherwise part ...
>
> Best,
> Christoph
>
> ------------------------------
> *Von:* Squeak-dev <squeak-dev-bounces at lists.squeakfoundation.org> im
> Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>
> *Gesendet:* Samstag, 22. Februar 2020 18:36:01
> *An:* The general-purpose Squeak developers list
> *Betreff:* Re: [squeak-dev] Question regarding compilation of
> #caseOf:[otherwise:] messages
>
> Hi Christoph,
> could it be for the case when there is no otherwise?
>
> Le sam. 22 févr. 2020 à 18:24, Thiede, Christoph <
> Christoph.Thiede at student.hpi.uni-potsdam.de> a écrit :
>
>> Hi all,
>>
>>
>> this a question regarding the Compiler's implementation. I spent some
>> time on it but could not yet find a satisfying explanation. Maybe someone
>> of you can help me?
>>
>>
>> Let's look into MessageNode >> #emitCodeForCase:encoder:value:, which
>> contains the following passage:
>>
>>
>> (isLast and: [allReturn]) ifTrue:
>>
>>     [self emitCodeForJump: elseSize encoder: encoder]
>>
>>
>> Btw, the equivalent in #sizeCodeForCase:value: is:
>>
>>
>> (isLast and: [allReturn]) ifTrue: [thenSize := thenSize + (self sizeCode:
>> encoder forJump: elseSize)].
>>
>>
>> In the bytecode of a method, this will look like this:
>>
>>
>> 89 <23> pushConstant: 2
>>
>> 90 <88> dup
>>
>> 91 <76> pushConstant: 1
>>
>> 92 <B6> send: =
>>
>> 93 <9A> jumpFalse: 97
>>
>> 94 <87> pop
>>
>> 95 <22> pushConstant: #one
>>
>> 96 <7C> returnTop
>>
>> 97 <77> pushConstant: 2
>>
>> 98 <B6> send: =
>>
>> 99 <9A> jumpFalse: 103
>>
>> 100 <21> pushConstant: #two
>>
>> 101 <7C> returnTop
>>
>> *102 <90> jumpTo: 104 "here!"*
>>
>> 103 <20> pushConstant: 42
>>
>> 104 <87> pop
>>
>>
>> I cannot see when this jump would be ever reached.
>>
>> *Case 1:* Any case is selected, and because allReturn is true, its
>> inlined value block is guaranteed to #returnTop and thus not to reach the
>> last jump (in the above example, this happens in pc101).
>>
>> *Case 2:* No case is selected, so the execution will jump straightly to
>> the inlined otherwiseBlock (this is pc99 in the example).
>>
>> For what purpose do we need this jump (ex: pc102)? Should we maybe remove
>> it?
>>
>>
>> Are there any special situations in which #returns is true but there is
>> any code path that does *not* return? Some weird exception handling trick,
>> for example?
>>
>> Or was the dubious jump just designed as a fallback to catch any
>> hypothetic failures in any other component of the compiler system?
>>
>>
>> I removed the generation of this jump for testing and could not
>> investigate any anomalies so far. All compiler tests are passing - except
>> of a number of Decompiler tests, which probably would need to be updated as
>> well.
>>
>> Please find a minimum changeset in the attachment that demonstrates my
>> question.
>>
>>
>> I am looking forward to your replies!
>>
>>
>> Best,
>>
>> Christoph
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200222/2be75849/attachment-0001.html>