-
-
Notifications
You must be signed in to change notification settings - Fork 32k
Make dis.Instruction
more useful
#102676
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
Comments
Hi! These suggestions seem very useful and fairly doable for a bytecode newbie :) I'd like to have a stab at this! |
@tomasr8 Please give it a try. Are you familiar with https://devguide.python.org/ ? |
Yes, I've read it :) FWIW I have most of it working, just need to add some tests and update the docs. Though I'm away for a couple of days so ETA 1 week. |
Hi @gvanrossum, if you have time, would you mind having a look at the PR? Thanks! :) |
I will, but not in time for the 3.12 feature freeze (which is Monday May 22). This means we'll be aiming for 3.13. Sorry. |
Thanks for letting me know! And it's fine, I don't really care in which version this ends up :) |
I recently was playing with bytecode instructions and found that the
dis.Instruction
did almost what I needed, but not quite -- I ended up reimplementing it, mostly reinventing the wheel. I propose to improve this class in dis.py as follows:start_offset
: start of the instruction includingEXTENDED_ARG
prefixesjump_target
: bytecode offset where a jump goes (can be property computed fromopcode
andarg
)baseopname
,baseopcode
: name and opcode of the "family head" for specialized instructions (can be properties)cache_offset
,end_offset
: start and end of the cache entries (can be properties)oparg
: alias forarg
(in most places we seem to useoparg
)Of these, only
start_offset
needs to be a new data field -- the others can be computed properties. For my application,start_offset
was important to have (though admittedly I could have done without if I had treatedEXTENDED_ARG
as aNOP
). It just feels wrong thatoffset
points to the opcode butoparg
includes the extended arg -- this means one has to explicitly representEXTENDED_ARG
instructions in a sequence of instructions even though their effect (arg
) is included in theInstruction
.I also added a
__str__
method to myInstruction
class that shows the entire instruction -- this could call the_disassemble
method with default arguments. Here I made one improvement over_disassemble
: if the opname is longer than_OPNAME_WIDTH
but the arg is shorter than_OPARG_WIDTH
, I let the opname overflow into the space reserved for the oparg, leaving at least one space in between. This makes for fewer misaligned opargs, since the opname is left-justified and the oparg is right-justified.@isidentical @serhiy-storchaka @iritkatriel @markshannon @brandtbucher
Linked PRs
dis.Instruction
#103969The text was updated successfully, but these errors were encountered: