-
Notifications
You must be signed in to change notification settings - Fork 479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AVM: frame pointers #4319
AVM: frame pointers #4319
Conversation
9ee23c4
to
0822b24
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
took a quick pass, looks like interesting fine grained manipulation over stack. I think the subroutine scheme in Pyteal will benefit from it, by getting rid of allocating scratch slots (plausibly trivially).
0822b24
to
ec9f161
Compare
969600e
to
ab8ed01
Compare
144bcc6
to
d7b245f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking very good.
Still reading, but I wanted to provide some feedback at this juncture.
Codecov Report
@@ Coverage Diff @@
## master #4319 +/- ##
==========================================
+ Coverage 54.09% 54.21% +0.11%
==========================================
Files 401 402 +1
Lines 51659 51830 +171
==========================================
+ Hits 27947 28101 +154
- Misses 21355 21364 +9
- Partials 2357 2365 +8
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very useful functionality. Very much looking forward to seeing how PyTeal subroutines become sleeker and easier to handle thanks to all this.
I left several comments, some more nitpicky than others.
My biggest suggestion is that a solid e2e test for the functionality be included before a final merge.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good juncture to leave comments. Still reading
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Submitting a couple of more questions.
2ea3c34
to
3d4c884
Compare
Also, a lot of cleanup of type tracking with frame_* And, caught some examples of us not testing opcodes in "nonsense" tests because the opcode was a substring of another opcode, like & is a substring of &&. (Caught, because "bury" is a substring of "frame_bury") This means there is a change to the "old" compiled constants. This is normally not done, but here we added to an old nonsense test, we added the corresponding bytes to the compiled output.
aac5193
to
5937ea6
Compare
8ee62a7
to
21ff73b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except for the possibility of increasing costs for dupn
or proto
(maybe that investigation ought to be a separate issue?), this looks good to me
b213777
to
b58ff8e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I expect to add some more question in the afternoon, but might as well put some up now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All of the items that I have previously brought up have been considered.
No description provided.