Re: Draft sketch of bytecode generation

[Dan Sugalski]

At 6:34 PM +0000 10/27/02, Nicholas Clark wrote:

On Sun, Oct 27, 2002 at 11:54:08AM -0500, Dan Sugalski wrote:

 The bytecode segments can hold more than just bytecode. They can also
 hold the source that corresponds to the generated bytecode, the AST
 for the source that corresponds to the generated bytecode, the line
 number information for the generated bytecode (for error reporting),
 and potentially some pieces of raw binary data, both for program
 needs and potential future expansion.

On a serious note, I think column number information for syntax errors (if
available) would be useful for languages such as perl (and not just Befunge)
For example, it would let a single stepping debugger show you progress through
the statement.

I'm having visions of n-dimensional numbers for errors...

"Division by zero at (5, 6, 3) of foo.pl"

(Whatever we decide, we are *not* adding in time information--quantum or not, there's no way we're going to be throwing errors yesterday or tomorrow... :)

 > =item Add binary data chunk to segment

 Add in some raw binary data to the bytecode segment

For each call this puts the binary into its own chunk? If not, what's wrong
with having binary data stored as a "string" in the string constant pool?

This puts it in the binary data section. Partially for those compilers that want to throw extra non-string data into the bytecode for whatever reason, and partially for potential forwards-compatibility issues. We could, for example, consider the line number information for bytecode a piece of binary data. (Just binary data that we know more information about)
--
Dan

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