On Sun, May 30, 2010 at 12:52:42AM -0700, Peter Lobsinger wrote: > On Sun, May 30, 2010 at 12:01 AM, Stefan O'Rear <[email protected]> wrote: > > On Sat, May 29, 2010 at 11:38:58PM -0700, Peter Lobsinger wrote: > >> 3) Have a separate ops table for every bytecode segment, switch tables > > > > 3a) The core ops become merely a preloaded dynop table. Since you only > > pay for the ops you use (and a dispatch pointer is the same size as a > > single opcode_t), the huge table problem goes away. > > Does this mean that every PBC bytecode segment has to explicitly list > every op that it uses by a globally unique name in some sort of yet to > be created header? Seems like that might bloat PBC significantly.
packfile-ops-used-table (1 per segment):
1 word Number of dynop libraries used (N)
1 word Number of dynops used (M)
N * 1 string Dynop library name
M *
1 word Dynop library index
1 word Dynop index within library
If every op used in a PBC is unique, and none of the ops take arguments, that
triples PBC size. If a PBC uses every op at least once, it adds no more than
8K for core ops (on i386; compare to several megs for a large PBC).
If that's too much, it can be optimized:
packfile-ops-used-table:
1 word Number of dynop libraries used (N)
N *
1 string Name of library
1 word Number of ops used from library (M_k)
M_k words Indexes of ops used
However, this requires an additional pass over the to-be-generated packfile
to assign numbers to ops (version 1 can do it on the fly in one pass), and
IMCC might not be able to cope (I haven't read the code).
-sorear
signature.asc
Description: Digital signature
_______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
