RE: Draft sketch of bytecode generation

[Dan Sugalski]

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
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk