Message307564
| Author |
serhiy.storchaka |
| Recipients |
Demur Rumed, Mark.Shannon, benjamin.peterson, christian.heimes, mark.dickinson, nascheme, ncoghlan, pitrou, rhettinger, serhiy.storchaka, trent |
| Date |
2017年12月04日.13:16:14 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<7488811.rCEn5LsdNE@saraksh> |
| In-reply-to |
<a0d6b8f8-505e-8900-a191-f9d11b19eaac@free.fr> |
| Content |
> The problem is that makes the stack consumption of END_FINALLY variable.
> How about always consuming 6 items, even when most of them are unused
> padding?
Right. Though the value of the stack increment makes sense only for the case
1, because in other cases the next executed instruction is not the one
following END_FINALLY, but we need to reserve the stack for the case 3, and
counting additional "virtual" items in PUSH_NO_EXCEPT and END_FINALLY will
help to calculate the maximal stack consumption, even when in runtime they
push/pop only one item. This is yet one argument for special purposed opcode
PUSH_NO_EXCEPT (maybe I'll rename it to START_FINALLY or BEGIN_FINALLY). Other
reason -- this will help to determine bounds of finally blocks in the
frame.f_lineno setter. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2017年12月04日 13:16:15 | serhiy.storchaka | set | recipients:
+ serhiy.storchaka, nascheme, rhettinger, mark.dickinson, ncoghlan, pitrou, christian.heimes, benjamin.peterson, trent, Mark.Shannon, Demur Rumed |
| 2017年12月04日 13:16:14 | serhiy.storchaka | link | issue17611 messages |
| 2017年12月04日 13:16:14 | serhiy.storchaka | create |
|