-
Notifications
You must be signed in to change notification settings - Fork 490
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
Dynamic teal #2126
Dynamic teal #2126
Conversation
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.
Few comments and suggestions.
Please also consider adding backward branching tests into backward compatibility tests - like the program rejected before teal4 and accepted after
|
||
// Evaluate the program | ||
pass, err = eval(program, &cx) | ||
|
||
return pass, err | ||
return eval(program, &cx) |
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.
not needed change. This place was quite convenient place for debugging (breakpoints/dumpning some info)
func checkPushBytes(cx *evalContext) int { | ||
func checkPushBytes(cx *evalContext) error { | ||
opPushBytes(cx) | ||
return 1 | ||
return cx.err |
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.
it looks like check* functions needs to be moved to check.go
from the assembler
@@ -774,6 +771,41 @@ func opAddw(cx *evalContext) { | |||
cx.stack[last].Uint = sum | |||
} | |||
|
|||
func uint128(hi uint64, lo uint64) *big.Int { | |||
whole := new(big.Int).SetUint64(hi) |
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.
it is interesting why does not big
package like stack-allocated Int
s... Have you tried
whole := &big.Int{}
whole.SetUint64(hi)
...
?
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 think that's fine too, but why prefer two lines / statements instead of a single expression?
I wanted to use syntax that gave a single expression that produced a big.Int from a u64, especially since I needed similar syntax two lines later to create the low word.
@algorandskiy You asked about testing old backjumps. This test does that
It tests that you get an error in all version up to |
This allows callers to do less work. The consensus protocol was already being supplied, so Check() has everything it needed to do the right thing. This also consolidates the code that will act differently for dynamic teal costs.
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.
Looks good except removing cost checks from txn verifier for pre-eval checks. Scenario: submit a long v2 program with jump to the end on a new and old node before protocol upgrade. It will fail on the old (sum up check) and pass on new.
@@ -1097,7 +1094,7 @@ var dryrunCmd = &cobra.Command{ | |||
} | |||
pass, err := logic.Eval(txn.Lsig.Logic, ep) | |||
// TODO: optionally include `inspect` output here? | |||
fmt.Fprintf(os.Stdout, "tx[%d] cost=%d trace:\n%s\n", i, cost, sb.String()) | |||
fmt.Fprintf(os.Stdout, "tx[%d] trace:\n%s\n", i, sb.String()) |
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.
why not printing the cost after eval?
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.
Because it's hidden inside the evaluation function and not exposed. If we find it important enough, I could rework the interfaces.
LGTM |
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.
Lots of good stuff here. A few small tweaks.
Probably worth having a paragraph in README_in.md about the callstack, how it's invisible except to two instructions, and any depth limit.
cat >${TEMPDIR}/true.teal<<EOF | ||
#pragma version 3 | ||
int 1 | ||
return |
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.
don't need return
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.
Right this is a remnant from the teal-v2 test, where I wanted to be clear that I had v3 code (where return was introduced). I think it still makes some sense here because of that, but the one below should be changed to some v4 opcode.
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.
Nope, I'm wrong. return was in v2. So it's entirely extraneous. I guess I got in the habit of doing that in tests when I wasn't sure of the stack.
I'll add something in TEAL cannot do section - I'll create a new line about lack of indirect jumps and this will naturally fit there. (Though I'll do it the next PR, as I want to avoid having this thing run through CI again, until/unless I get feedback that needs a code change.) My current thinking is NOT to restrict the call depth, and to simply let that be limited by the runtime of the program. That means a program of |
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.
Looks good!
My current thinking is NOT to restrict the call depth, and to simply let that be limited by the runtime of the program. That means a program of
loop: callsub loop
would get 20,000 deep in a logicsig, but that's just a 20k int array that immediately goes away. Didn't seem to matter. Thoughts?
From a programmer/debugger standpoint this seems like a good approach, though I can't comment on whether that's a significant memory usage or not.
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.
Few minor issues mentioned above, but overall looks great.
I would be happy to see more extensive testing around the new teal opcodes - maybe some teal code that is doing a dual/triple recursion ?
I'll do a mutually recursive odd() / even() implementation. |
acbc483
Aw crap. I committed some changes to address @tsachiherman comments. So now approvals are dismissed. Once I get through CI, I'll ping for them again. Sorry. |
Add support for dynamic TEAL.
No description provided.