1.4 bytecodehacks.label

Label is not, as it happens, necessary. The functionality could be folded into the opcode classes. It is a useful abstraction, in that it stops my head hurting so much when I think about jumps, so it stays. A Label is just that, a label that denotes a particular opcode. They are the targets of jumps. User code will not need to create Labels.

About all you'll actually be doing to a Label is redirecting its op attribute. This points to the target of the jump.

For completeness, and for my memory, here are the methods of the Label class:

Label ([byte])

Create a label. If byte is supplied, it should be the address of the target of the jump. If byte is supplied then resolve should be called at some point to enable the target opcode to be found.

In user code, byte will typically not be supplied, and the op attribute will be set directly.

resolve (code)

Called by CodeString during construction; an invitation to resolve a opcode reference specified by passing byte to the constructor.

add_absref (byte)

Request that the address of self.op be written to the argument of the opcode starting at byte in the codestring.

add_relref (byte)

Request that the relative address of self.op be written to the argument of the opcode starting at byte in the codestring.

write_refs (cs)

Write the addresses requested by calling add_relref or add_absref to cs (a file-like object, most like a StringIO).

byte

A variable that holds the address of the target opcode between Label construction and the calling of resolve.

op

The target opcode.

absrefs

A list of addresses of opcodes that wish to have absolute target addresses written to their argument portion.

relrefs

A list of addresses of opcodes that wish to have relative target addresses written to their argument portion.

In the current implementation I think each Label will only have to write one reference. However the ability to write more than one might come in handy one day, so it stays.