Jason --
Originally, I considered adding an optable segment to the packfile format
and no useop op.
After considering useop, I found the idea of a conventional (but
technically optional, TMTOWTDI) preamble
and the ability to modify the optable while running intriguing.
There is value to using an optable segment to pick the ops for the code
segment, even if none of the more
dynamic stuff is done.
Retaining the ability to modify the optable at runtime is still
interesting, to me. It essentially makes the
optable a shortcut for the useop preamble. However, retaining this ability
means that any generic
disassembler will have to be useop aware, which is what I think you are
trying to avoid.
Regards,
-- Gregor
Jason Gloudon <[EMAIL PROTECTED]>
11/04/2002 11:41 AM
To: [EMAIL PROTECTED]
cc: Leopold Toetsch <[EMAIL PROTECTED]>, Brent Dax <[EMAIL PROTECTED]>, "'Andy
Dougherty'" <[EMAIL PROTECTED]>, Josh Wilmes <[EMAIL PROTECTED]>,
"'Perl6 Internals'" <[EMAIL PROTECTED]>
Subject: Re: Need for fingerprinting? [was: Re: What to do if
Digest::MD5 is
unavailable?]
On Sun, Nov 03, 2002 at 04:59:22PM -0500, [EMAIL PROTECTED] wrote:
> 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
One question this raises is where does this initialization occur ?
I think the information that would be encoded in these instructions should
normally go into a metadata section of the bytecode stored on disk. Having
to
pseudo-execute the bytecode in order to disassemble seems unnecessary. I
think
keeping this information separete from the executable section will make
the
code generators simpler as well.
--
Jason
