--- "Gregor N. Purdy" <[EMAIL PROTECTED]> wrote: > Brian -- > > > > None of these are issues with the approach I've been > working on / > > > advocating. I'm hoping we can avoid these altogether. > > > > > > > I think this is a cool concept, but it seems like a lot > of overhead with > > the string lookups. > > I'm hoping we can keep the string lookups in order to > sidestep the > versioning issue. They can be made pretty cheap with a > hashtable or search > tree, and the lookups only happen once when we load. And, > we may even be > able to create the tree or hash table structure as part > of the oplib.so, > so we don't even have to pay to construct it at run time. > I guess I'm > making the provisional assumption that by the type we go > out and > dynamically load the oplib, a few op lookups by name > won't be too big a > deal if we are smart about it. Of course, I could be > wrong, but I'd like > to see it in action before passing judgement on it. [snip]
Better than doing two string lookups for every op we use ("library", "op_name"), we can vector the library through the fixup section. This is sort of how I at least envision accessing global variables: the fixup has an entry (PAR_FIXUP_GLOBVAR, strtab_ref("$foo")), where strtab_ref() is the index of a string in the string table. So loading another oplib becomes as simple as (PAR_FIXUP_OPLIB, "core"). The individual op descriptors then simply reference the fixup for that library, which after fixup contains the global index of the library. Actually, if libraries are good about not reusing op numbers, we don't have to do _any_ string lookups. Since we're building each module's op table at load time anyway, we don't loose any cache space by not reusing op numbers, since unused ops will never show up in any module's table. e.g. ..use core ..use perl set I0, 2 set I1, 3 add I3, I0, I1 fetch P0, "$foo" inc P0 produces # .section .fixup PAR_FIXUP_OPLIB, 1 PAR_FIXUP_OPLIB, 2 PAR_FIXUP_OPTABLE_SIZE, 4 # put this here so .optable can # be processed w/o any special # cases and we can prealloc the # table PAR_FIXUP_VARREF, 3 # this becomes the pointer to the # entry in the symbol table (not # the variable itself - its slot # in the table so that aliasing # works right) # .section .strtab "core" "perl" "$foo" # .section .optable 1, 54 # core::set_i_ic 1, 33 # core::add_i_i_i 2, 1 # perl::fetch_p_ic 2, 23 # perl::inc_p # .section .text # numbers are the actual opcode/operand values 1 0 2 1 1 3 2 3 0 1 3 0 4 4 0 By using this scheme we manage to not do _any_ string lookups, and if we pick our base set of ops well enough that we don't end up obsoleting many of them, we also won't be using as much memory as the string lookups would require. -- BKS __________________________________________________ Do You Yahoo!? Find a job, post your resume. http://careers.yahoo.com