Leo --
Here's one of the early fingerprinting patches, 2001-09-14:
http://archive.develooper.com/perl6-internals@;perl.org/msg04063.html
Here's where Simon removed Digest::MD5, 2001-09-18:
http://archive.develooper.com/cvs-parrot@;perl.org/msg00151.html
Here's one of the messages about how I'd like to see us link op
implementations with their op codes:
http://archive.develooper.com/perl6-internals@;perl.org/msg06193.html
You can use that to vector into the thread. My ideas have changed a bit
since then (see below), but
you can get some of the idea there.
Here's another message that touched on this kind of stuff:
http://archive.develooper.com/perl6-internals@;perl.org/msg06270.html
What I advocate is having possibly only one (maybe too extreme, but
doable) built-in op pre-loaded
at opcode zero. This op's name is "useop", and its arguments give an
opcode (optable index), and
sufficent information for the interpreter to chase down the opinfo (and
opfunc). In the best scenario, this
could mean even doing some dynamic loading of oplibs. BTW, that was the
point of my initial bloated-
but-lightning fast oplookup switch() tree implementation, which has now
been replaced with something
I expect is more sane (I went that extreme because I was getting push-back
that the by-name lookups
would be slow, and even though I never advocated looking them up in DO_OP,
I still wanted to
demonstrate that they could be *very* fast).
Now, whether or not you statically link other oplibs, I suggest not having
every op be allocated a slot
in the optable. Rather, the initial few ops in the startup code of a chunk
of Parrot code is responsible
for utilizing useop to arrange the appropriate optable for that code. For
example, assembling
mops.pasm would result in the first chunk of code making 13 calls to useop
to attach the ops used by
that code. No longer to we care what order ops are in their oplibs,
because opcodes are not a
meaningful concept at a static level (in the Parrot source).
I've noticed that the current setup concats *.ops into one big core_ops.c,
which is very different from
what I was trying to move us towards long ago. I'm an advocate of smaller
and independant *.ops
files, separately compiled, and (possibly) only some actually statically
linked in. An additional by-name
lookup will be needed to map oplib names (and possibly version info, if we
determine that is necessary)
to the oplibinfo structures we got from the statically or dynamically
linked oplibs. The oplibinfo structures
give you the function pointer to call to look up ops by name in that
oplib.
One final interesting (at least to me) note: A chunk of code could
overwrite the optable entry zero with
some noo?p-equivalent op to prevent any further changes to its optable
once it has things the way it
wants them.
Regards,
-- Gregor
Leopold Toetsch <[EMAIL PROTECTED]>
11/03/2002 02:49 PM
To: [EMAIL PROTECTED]
cc: Josh Wilmes <[EMAIL PROTECTED]>, Brent Dax <[EMAIL PROTECTED]>,
"'Andy
Dougherty'" <[EMAIL PROTECTED]>, "'Perl6 Internals'"
<[EMAIL PROTECTED]>
Subject: Re: Need for fingerprinting? [was: Re: What to do if
Digest::MD5 is
unavailable?]
[EMAIL PROTECTED] wrote:
> All --
>
> FWIW, this stuff came up early on in Parrot's infancy.
Pointers, hints, information ...
> On a related note, I'm working on a toy VM outside of Parrot to
> demonstrate the technique I've proposed here in the past,
Pointers, hints, information ...
thanks,
leo ;-)
