[pypy-dev] Getting involved

[John Smith]

Hi Eleytherios,

It looks to me like this is already done. Using the `dis` module and a
simple generator you can see that POP_BLOCK is only called when the
loop ends (which it never does in this example) but it remains after
each value is yeilded (YIELD_VALUE).

def f():
    while True:
        yield 3

dis(f)
  2           0 SETUP_LOOP              15 (to 18)
        >>    3 LOAD_GLOBAL              0 (True)
              6 POP_JUMP_IF_FALSE       17

  3           9 LOAD_CONST               1 (3)
             12 YIELD_VALUE
             13 POP_TOP
             14 JUMP_ABSOLUTE            3
        >>   17 POP_BLOCK
        >>   18 LOAD_CONST               0 (None)
             21 RETURN_VALUE


Best,
J

On Thu, Jul 10, 2014 at 9:52 AM, Eleytherios Stamatogiannakis
<estama at gmail.com> wrote:
> Hi all, and sorry for interjecting.
>
> Concerning the concept of leaving a function's stack in place.
>
> Can the same idea be used for generators? So when we yield (return) from a
> generator, we don't erase its stack but leave it in place to be reused for
> the next call to it.
>
> l.
>
>
> On 10/07/14 16:39, John Smith wrote:
>>
>> Hi Armin,
>>
>> I don't see why a new bytecode would be needed. I'm not sure exactly
>> how Python functions are called, but this is based off what I know of
>> X86 assembly and from what I gathered from Laurie's blog. Why not push
>> the new arguments onto the stack and then jump back to the beginning
>> of the function so as to reuse its stack frame? Which could all be
>> done with the current bytecodes.
>>
>>  From a bigger picture perspective this and other compiler
>> optimizations which change the traceback may be a good fit for use
>> under the  "-O" flag. Default behavior will be unchanged, and they can
>> be added when wanted.
>>
>> Best,
>> J
>>
>>
>> Hi John,
>>
>> On 8 July 2014 22:57, John Smith <4u5vjqpb at gmail.com> wrote:
>>>
>>> Yes. But tail-call optimization is a performance optimization, so it goes
>>> well with PyPy. I wanted to suggest to Travis that he not be discouraged
>>> from his idea and give him another idea for getting tail-call more widely
>>> used compared to making his own fork of PyPy.
>>
>>
>> Yes, that sounds like an idea --- which I wouldn't call a *good* idea
>> because I still think that tail call optimization is a bad idea in
>> Python, but that's a personal issue.  If you want to implement such a
>> pure Python compiler modification, you can; but it's a bit unclear
>> what kind of alternate Python code or bytecode to emit.  We could
>> consider adding an experimental bytecode to the standard PyPy, even if
>> it is normally never used, as long as it's extensively tested.
>> Designing the bytecode correctly is an open question.
>>
>>
>> A bientôt,
>>
>> Armin.
>> _______________________________________________
>> pypy-dev mailing list
>> pypy-dev at python.org
>> https://mail.python.org/mailman/listinfo/pypy-dev
>>
>
> _______________________________________________
> pypy-dev mailing list
> pypy-dev at python.org
> https://mail.python.org/mailman/listinfo/pypy-dev