-
Notifications
You must be signed in to change notification settings - Fork 14
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
add stats for upper bound on number of registers #130
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.
Glad this old script is still useful!
len(co.co_cellvars) + | ||
len(co.co_consts) + | ||
len(co.co_freevars) + | ||
len(co.co_names) + |
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 don’t see why names should go in registers. The name itself is not data to be loaded, it is a parameter to the instruction ( e.g. LOAD_ATTR).
same for co_varnames.
And isn’t co_lnlocals the sum of three others?
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.
We don't need to merge this PR, it was just to get an idea. There were very few functions with >255 registers even with all this over-counting, so it's not going to be an issue if we need the occasional EXTENDED_ARGS.
Results of
./python.exe scripts/count_opcodes.py --registers ./packages/*
:(full results in a comment below).