--- "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

Reply via email to