Closed
Bug 474021
Opened 16 years ago
Closed 16 years ago
Mapping from opcode to stack movement
Categories
(Tamarin Graveyard :: Virtual Machine, defect)
Tamarin Graveyard
Virtual Machine
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: lhansen, Assigned: lhansen)
References
Details
Attachments
(1 file)
32.36 KB,
patch
|
edwsmith
:
review+
|
Details | Diff | Splinter Review |
Patch incorporates stack movement information into opcode table. (Those opoces that have variable stack movement are given information corresponding to their movement when the variable portion is 0; client code must incorporate the variable portion as appropriate.) Adds one field to the AbcOpcodeInfo structure, which probably effectively adds one word to it. It would be possible to shrink several fields (encode as bitfields rather than bytes) so that that word is recovered if that is thought important. The new mapping is used by run-time compiler.
Attachment #357410 -
Flags: review?(edwsmith)
Comment 1•16 years ago
|
||
call opcodes and multiname opcodes have additional stack movement implied in their operand data. obviously, not in the table; is the idea that the table's value is added to this computed value? (if the rule above is used, i'd expect 0 for e.g. OP_callproperty, and -1 for OP_callpropvoid, which is what i'm seeing)
Comment 2•16 years ago
|
||
nevermind, it helps to read the comments highlighted in green
Updated•16 years ago
|
Attachment #357410 -
Flags: review?(edwsmith) → review+
Assignee | ||
Comment 3•16 years ago
|
||
redux changeset: 1310:a99aba358731
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•