--- Juergen Boemmels <[EMAIL PROTECTED]> wrote:
> Hello,
>
> after quite a long time away from keyboard and fighting through a
> huge
> backlog of mail I'm (hopefully) back again.
>
> Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> > Since it looks like it's time to extend the packfile format and the
> > in-memory bytecode layout, this would be the time to start
> discussing
> > metadata. What sorts of metadata do people think are useful to have
> in
> > either the packfile (on disk) or in the bytecode (in memory).
>
> My current idea for the in memory format of the bytecode is this:
> One bytecodesegment is a PMC consisting of three parts the actual
> bytecode (a flat array of opcode_t), the associated constants, which
> don't fit into an opcode_t (floats and strings), and a scratch area
> for the JITed code. All other Metadata will be attached as
> properties (or maybe as elements of an aggregate). This will be an
> easy way for future extension. The invoke call to this pmc would
> simply start the bytecode from the first instruction.
>
> To support inter-segment jumps a kind of symboltable is also
> neccessary. All externally reachable codepoints need some special
> markup. This could be a special opcode extlabel_sc or an entry in a
> symboltable. Also needed is a fixup of the outgoing calls, either via
> modification of the bytecode or via a jumptable. Both have their pros
> and cons: The bytecode modifcation prohibits a readonly mmap of the
> data on disk and the fixup needs to be done at load-time but once
> this
> is done the impact on the runtimespeed is minimal, whereas the
> jumpcode is on extra indirection. But as stated somewere else the
> typical inter-segment jump will be call/tailcall/callmethod/invoke,
> which are at least two indirections.
>
> The on disk version is a matter of serializing and deserializing this
> PMC.
>
> > Keep in mind that parrot may be in the position where it has to
> ignore
> > or mistrust the metadata, so be really cautious with things you
> > propose as required.
>
> Ok to summarize:
>
> ByteCodeSegment = {
> bytecode => requiered;
> constants => only neccessary if string or num constants;
> fixup => (or jumptable) only neccessary if outgoing jumps;
> symbols => all possible incomming branchpoints, optional;
> JIT => will be filled when bytecode is invoked;
>
> source => surely optional;
> debuginfo => also optional;
> ...
> }
I LIKE IT.
Bytecodes have a type? each bytecode has meta-data?
Here are the metadata I have collected from the parrot source code so
far. It should be a set of predicates to define all the other meta-data
needed.
First, this is the core meta-data for storing perl code :
in order of simplicity
identifier_node
Name of things
boolean_type,integer_type,real_type
types of things that are simple
all *_decls have a type that is a type_*
all *_decls have a name that is a type_decl or identifier_node
const_decl
Constant values
var_decl
variable values
The rest of the more complex types need a tree_list
tree_list
function_decl,
parm_decl # list of
array_type
integer_cst, # list of
enumeral_type
integer_cst # list of
record_type,union_type,
field_decl # list of
# a void is very special
void_type
The following are derived types :
pointer_type,reference_type
# function types allow for linkage
function_type,
type_* # we have a list of
# here the user defines its own
type_decl
# this is a commonly defined user type
complex_type,
=====
James Michael DuPont
http://introspector.sourceforge.net/
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
