Front page | perl.perl6.internals |
Postings from October 2002
RE: Draft sketch of bytecode generation
Thread Previous
|
Thread Next
From:
Dan Sugalski
Date:
October 28, 2002 13:08
Subject:
RE: Draft sketch of bytecode generation
Message ID:
a05111b01b9e356740664@[63.120.19.221]
At 11:40 PM -0800 10/27/02, Brent Dax wrote:
>Dan Sugalski:
># =item Add source code to segment
>#
># This adds a line or more of source code to the bytecode segment.
>
>Optional?
Yes.
># =item Add AST to segment
>#
># This adds the AST for some of the source code to the bytecode segment.
>
>Optional?
Yes.
># =item Add line number information
>#
># This adds line number info to the bytecode segment, allowing
># the interpreter to find out what line of source a particular
># piece of bytecode corresponds to.
>
>Optional?
Yes.
># =item Add bytecode to segment
>#
># Add in actual bytecode to the segment.
>
>Not optional. :^)
No. :)
There's no reason this can't be optional, though at that point you
don't have an *executable* bytecode segment. That doesn't mean it
can't otherwise be useful.
># =item Add constants (string, PMC, and float)
>#
># Add one or more constants to the bytecode constant pool
>#
># =item Add symbols to segment
>#
># Add in symbolic information to the bytecode segment,
># including exported variables, classes, and functions
>
>Optional?
Yes.
># =item Add binary data chunk to segment
>#
># Add in some raw binary data to the bytecode segment
>
>Optional?
Yes.
>Can you have multiple raw chunks? Can they have symbolic names?
>Symbolic type names?
Yes, maybe, and maybe, respectively. I hadn't planned on anything
past "raw binary data segment #n, subtype Y" for them.
>Are the other chunks essentially subclasses of this one?
They could be considered as such, yeah, but they probably won't be in practice.
Chunks, I think, need a type and subtype attached to them. The type
for binary data will be "raw hunk 'o binary data" while the subtype
can be something else, which the program using the bytecode would
presumably have some knowledge of.
>Is there some kind of directory that tells you stuff about these chunks?
Yes, we're going to have to have one.
>If there is, I can imagine two basic formats:
>
>SEGMENT 1
> DIRECTORY
> CHUNK 1
> OFFSET: 100 (4 bytes)
> SIZE: 55 (4 bytes)
> NAME: "src" (7 bytes)
> TYPE: "Parrot::Source Code" (23 bytes)
> CHUNK 2
> OFFSET: 155
> SIZE: 524
> NAME: "bc"
> TYPE: "Parrot::Bytecode"
> ...
> CHUNK 1
> use strict;
> use warnings;
> print "Hello World!\n";
> exit;
> CHUNK 2
> 101011101...
>
>Or
>
>SEGMENT 1
> DIRECTORY
> CHUNK 1 OFFSET: 100
> CHUNK 2 OFFSET: 189
> CHUNK 1:
> SIZE: 55
> NAME: "src"
> TYPE: "Parrot::Source Code"
> DATA: ...
> CHUNK 2:
> SIZE: 524
> NAME: "bc"
> TYPE: "Parrot::Bytecode"
> DATA: ...
Hrm. Probably the former, though there is definitely an advantage to
keeping the metadata for a chunk with the data itself. Makes
extraction utilities a lot easier to work with, and makes the file a
bit less prone to damage, though arguably once it's damaged you're
pretty hosed. (OTOH, having had files creamed before, I do understand
the advantage to being able to extract *something* meaningful out of
the file, even if you can't get everything)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk
Thread Previous
|
Thread Next