On Thu, Jan 23, 2003 at 02:48:38PM -0800, Brent Dax wrote:
> Are you expecting to have chunk type determined by order? If so, what
> will you do if a future restructuring means you either don't need chunk
> type X or you need a new, highly incompatible version? Will you leave
> in an "empty" ghost chunk?
>
> I would suggest (roughly) the following format for a chunk:
>
> TYPE: One 32-bit number
> VERSION: One 32-bit number; suggested usage is as four eight-bit
> components
> SIZE: One 32-bit number of bytes (or maybe 64-bit)
> DATA: arbitrary length
>
> For C-heads, think of it like this:
>
> struct Chunk {
> opcode_t type;
> opcode_t version;
> opcode_t size;
> void data[];
> };
I agree with the "roughly" bit, but I'd suggest ensuring that you put
in enough bits to get data[] 64 bit aligned. Mainly because at least 1
architecture exists that has no 32 bit types (Crays I know about; others
may exist. I can't remember if perl 5.8 passes 100% of tests on Crays.
We certainly tried)
> If there's a directory of some sort, it should record the type ID and
> the offset to the beginning of the chunk. This should allow for a
> fairly quick lookup by type. If you think that there might be a demand
> for multiple instances of the same type of metadata, you may want to add
> a chunk ID of some sort.
It might be useful for making "portable" fat bytecode.
On Thu, Jan 23, 2003 at 01:39:03PM -0500, Dan Sugalski wrote:
> At 10:29 PM -0800 1/22/03, James Michael DuPont wrote:
> >You will probably think that this is overkill for parrot,
>
> Why yes, yes I do. On the other hand, when we hand people bazookas to
> deal with their fly problems, we often find they start in on the
> elephant problems as well.
No wonder the rolls of sticky elephant paper never sold.
> The proposal in general interests me--it looks like a general
> annotation system we can attach to the bytecode. (I admit, I haven't
> read the page you pointed at) I will admit, though, that I was
> thinking more about metadata that the engine could use itself, or
> would provide to programs running on it, but the scheme you've
> outlined may be useful for that.
I'm thinking that register usage information from imcc could be of use
to the JIT, as that would save it having to work out things again. So that
probably needs a segment.
Also some way of storing a cryptographic signature in the file, so that you
could compile a parrot that automatically refuses to load code that isn't
signed by you.
On Thu, Jan 23, 2003 at 05:05:54PM -0500, Dan Sugalski wrote:
> Which will generally be the case, I expect. Tell a sysadmin that they
> can reduce the memory footprint of mod_parrot by 50% by running a
> utility (that we provide in the parrot kit) over the library and I
> expect you'll see smoke from the keyboard as he/she whips off the
> command at supersonic speeds... :)
Followed by writs for claims for supersonic RSI addressed to p6i
On Fri, Jan 24, 2003 at 07:59:13AM +0100, Leopold Toetsch wrote:
> Juergen Boemmels wrote:
>
> >Dan Sugalski <[EMAIL PROTECTED]> writes:
>
>
> >It might be even possible to dump the jitted code. This would increase
> >the startup. Then strip the bytecode to reduce the size of the file
> >and TADA: Yet another new binary format.
>
>
> When you then are able to to get the same memory layout for a newly
> created interpreter, it might even run ;-)
So the JITted code contains lots of hard references to address in running
interpreter? It's not just dependent on that particular binary's layout?
I guess in future once the normal JIT works, and we've got the pigs flying
nicely then it would be possible to write a Not Just In Time compiler that
saves out assembly code and relocation instructions.
Bah. That's "parrot -o foo.o foo.pmc" isn't it?
Nicholas Clark
