Closed
Bug 608203
Opened 14 years ago
Closed 6 years ago
ABC: Add a means of creating Array, ByteArray, and Vector data from a literal list of values
Categories
(Tamarin Graveyard :: Virtual Machine, defect)
Tamarin Graveyard
Virtual Machine
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: lhansen, Unassigned)
References
Details
Currently an initializer for aggregate data can be represented in two ways:
- as code, eg:
pushint; pushint; ...; newarray
newarray; dup; pushint; setprop; dup; pushint; setprop; ...
- as string data
pushstring
It would probably be helpful for both performance and ABC compactness if we had a more general facility wherein the ABC could carry a sequence of values and operate on these as a group to create the aggregate data.
For example, consider this array initializer:
[1,3,5,7,11,13,17,19,23,27]
This could be represented as a sequence of integer values in the int constant pool and a new instruction, which I will call NEWARRAY3, which takes a constant pool identifier, a start index in that pool, and a number of consecutive pool elements and creates the array:
newarray3 0, 7, 10
Similarly there could be instructions to construct ByteArray and Vector.<int>, Vector.<uint>, and Vector.<Number> data.
Comment 1•14 years ago
|
||
Wouldn't such a format potentially increase the size of the constant pool by a fair amount? Currently, I thought that the constant pools never had duplicates (for example, you would only have one 42 in the pool, and instructions using 42 would all reference 42's single index in the pool).
You'd run into at least two kinds of duplication:
[1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1] // where you have the same number repeated
and
[2, 0xdeadbeef, 4], [17, 0xdeadbeef, 4] // where two arrays share a weird constant
That problem intensifies with things like string-filled arrays, where you'd have to duplicate repeated strings in the pool if you wanted to have unique ranges for each initializer.
This proposed newarray3 would certainly compact the size of bytecode blocks within MethodBodyInfos, but it's hard for me to make a good guess about whether it would help or hurt the overall ABC size. Perhaps the compression of the SWF would eliminate any size concerns about the constant pools.
Comment 2•6 years ago
|
||
Tamarin is a dead project now. Mass WONTFIX.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Comment 3•6 years ago
|
||
Tamarin isn't maintained anymore. WONTFIX remaining bugs.
You need to log in
before you can comment on or make changes to this bug.
Description
•