Is load_bytecode supposed to provide "do" semantics (reload the packfile every time the op is executed) or "require" semantics (load the packfile only if it hasn't been loaded already)? I think the only distinction at the moment would be whether the extra time of rereading the file is performed. Might there be an "init" function of some sort called at load time, or is that better left to the high-level language?
Load_bytecode "foo.pbc" seems solid now. Load_bytecode "foo.imc" is still giving me a few problems. 1) Two instances of C<load_bytecode "stream.imc"> in the same file causes segmentation fault when returning from the second call into stream.imc. 2) C<$P0 = global "_sub_in_the_current_file"> works when running PBC. When doing a compile&run from PIR, it seg faults. Should I write tests for these two cases? What is the plan for extracting linking information from packfiles? For the moment, I'm defining a sub "__du" (description unit) that provides the CLU-specific information my compiler needs. My understanding is that the information necessary for PCC calls (subroutine type, proto/unproto, register types of params and returns for proto) will be in the packfile within a few versions. What about other information the higher-level language wants to store (a list of exceptions thrown, type information beyond register type, typedefs, constants, etc.)? I'm picturing something like CORBA's IDL, only hopefully not as ugly. --kag
