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.
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.
You need to log in before you can comment on or make changes to this bug.