--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 07:36 PM 9/25/2001 -0400, Gregor N. Purdy wrote:
> >I'm just waiting for the thumbs-up from Simon and Dan
> before committing
> >that increment and then moving on to do the changes to
> the format to
> >support more than just strings in const_table. A cooler
> packfile/
> >bytecode file format is due post-0.0.2.
>
> Okay, here's a quick idea of how things should work.
>
>
> *) Add a "current_fixup_section" pointer to the
> interpreter structure
> *) Add a "set_fixup_section" opcode which fills in this
> pointer
> *) The generated bytecode segment should be padded on the
> end with NULLs to
> an even multiple of 8K.
> *) Immediately after the padded bytecode (in the on-disk
> image and in
> memory) is the fixup section. This is a list of 8-byte
> entries. The zeroeth
> entry corresponds to the zeroeth constant. On disk these
> can be anything
> you feel appropriate.
> *) At bytecode load time we turn the constants into real
> things in memory
> however we need.
> *) At bytecode load time we run through the fixup section
> and put in real
> pointers to the appropriate constants.
> *) All constant access other than 32-bit integers is now
> "load entry x from
> the table pointed to via current_fixup_section"
>
> Whether we have a set of get_constant_FOO(x) functions
> for the various
> types of FOOs or just force casting is up in the air.
>
> Make sense? There's good reason for it, really there is.
Just to make sure that it's making the _right_ sense, the
fixup section is basically our single level of indirection
so that we can make the bytecode itself be
position-independant, right? But why store it in this
format? What we really need to store is the list of what we
expect in the table and where. This gets more important
when we add in PMCs - we'll want the fixup table to provide
our local binding to the (interpreter-)global symbol table.
To do that, we need fixup entries like:
struct fixup {
int32 type; /* FIXUP_I64, FIXUP_NV, FIXUP_PMC, etc. */
union {
STRING str_val;
I64 i64_val;
NV nv_val;
... /* all the various thing we can fix up */
};
};
and we need to ensure the same structure padding on all
platforms if we really want to be able to load code from
other systems. Beyond the data to _build_ the table, what
else do we need? Can't we just have the bytecode header
have
int32 *data_template;
int32 fixup_space_needed;
and build the final table as needed?
-- BKS
__________________________________________________
Do You Yahoo!?
Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger.
http://im.yahoo.com
