> If you already analyzed it, I trust you, you are more advanced than me on the subject :)


I would not say that I have an overview of the entire compiler system at the moment. Someone else should definitively review this before. :)

> 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 :)

Hm, maybe this could be some of my next adventures :-)
(At the moment I'm trying to optimize #caseOf: to use binary search if appropriate, let's see what will come of it ^^)

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:50:26
An: The general-purpose Squeak developers list
Betreff: Re: [squeak-dev] Question regarding compilation of #caseOf:[otherwise:] messages

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<mailto: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<mailto:squeak-dev-bounces at lists.squeakfoundation.org>> im Auftrag von Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com<mailto: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<mailto: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/145030c0/attachment.html>