develooper Front page | perl.perl6.internals | Postings from October 2002

RE: Draft sketch of bytecode generation

Thread Previous | Thread Next
Dan Sugalski
October 28, 2002 13:08
RE: Draft sketch of bytecode generation
Message ID:
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.


># =item Add AST to segment
># This adds the AST for some of the source code to the bytecode segment.


># =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.


># =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


># =item Add binary data chunk to segment
># Add in some raw binary data to the bytecode segment


>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:
>		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"
>		...
>		use strict;
>		use warnings;
>		print "Hello World!\n";
>		exit;
>		101011101...
>		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)

--------------------------------------"it's like this"-------------------
Dan Sugalski                          even samurai                         have teddy bears and even
                                       teddy bears get drunk

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About