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.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
