["BUG"][FIX?]Incorrect Pseudo-Code for
#whileTrue:/#whileFalse:?
Andrew C. Greenberg
werdna at mucow.com
Tue Jan 2 15:23:28 UTC 2001
At 8:14 AM -0500 1/2/01, Andrew C. Greenberg wrote:
>At 10:54 AM -0800 1/1/01, Randal L. Schwartz wrote:
>> >>>>> "Andrew" == Andrew C Greenberg <werdna at mucow.com> writes:
>>
>>Andrew> It's possible that I'm just not getting it, but it would appear that
>>Andrew> the pseudo-code for #whileTrue; and #whileFalse: is incorrect. Even
>>Andrew> if I were right, it is still the height of pedantry on my
>>part to call
>>Andrew> this a bug, since the code is never executed due to
>>compiler inlining.
>>Andrew> Nevertheless, perhaps it would be more aesthetically pleasing to have
>>Andrew> pseudo-code here that would work if the compiler did not
>>inline loops?
>>
>>Andrew> The present code in BlockContext is:
>>
>>>> whileTrue: aBlock
>>>> "Ordinarily compiled in-line, and therefore not overridable.
>>>> This is in case the message is sent to other than a literal block.
>>>> Evaluate the argument, aBlock, as long as the value of the
>>>> receiver is true."
>>>>
>> >> ^ [self value] whileTrue: [aBlock value]
>>
>>Your change makes sense if the compiler did not recognize this as a
>>special case, although it would suffer from recursion trouble if there
>>was no tail-recursion optimization (which there isn't, if I recall
>>from the last time I asked about this same thing).
>
>It would appear that the assumption of inlining would benefit both
>sets of code, and would suffer the same tail-recursion problem in
>both cases if it did not. The difference I see is that I understand
>why the more traditional:
>
> ^self value ifTrue: [aBlock value. self whileTrue: aBlock]
>
>would work, but I don't understand how the existing code could EVER
>work. It is apparent that I am missing something. Please clarify.
Sorry. Lightbulb went off when I looked at the bytecodes for each
alternative. Clearly, the status quo generates the desired result
precisely because of the assumption of inlining of the bytecodes and
blocks, to wit:
5 <70> self
6 <C9> send: value
7 <9C> jumpFalse: 13
8 <10> pushTemp: 0
9 <C9> send: value
10 <87> pop
11 <A3 F8> jumpTo: 5
13 <73> pushConstant: nil
14 <7C> returnTop
Perhaps the comment could be clearer?
More information about the Squeak-dev
mailing list
|