Re: Dynamic Evaluation & Precompiled Bytecode

Avatar wrote:


> I am researching the development of a dynamic language similar in many
> respects to popular "scripting" languages like perl, python, and ruby.
>
> The high-level language should be compiled to bytecode which is then
> executed within a VM.
>
> The language should alos support dynamic code evaluation which would
> necessitate on-the-fly compilation into bytecode. Is it possible for a
> dynamic language to support both forms of generated bytecode?
>
> My specific question has to do with the representation of symbolic
> information within precompiled versus on-the-fly compiled bytecode. If
> a program is precompiled into bytecode and symbolic information (ie.
> variable names) is encoded into the precompiled bytecode... How can
> dynamically compiled bytecode that may reference some of those same
> symbols (ie. variables) be accurately resolved?


In e.g. SMalltalk bytecode is embedded in an object system that contains
the information. For example a method '+' that adds things to x,y
Points might look like this at the source level:


+ aValue
          | valueAsPoint |
          valueAsPoint := aValue asPoint.
          ^Point x: x + valueAsPoint x y: valueAsPoint y


the method object might look like this (where "->" means "points to", or
"has value"):


          1st inst var bytes -> a ByteArray of the bytecode
          2nd inst var class -> the class Point
          slot 3 -> #asPoint (message selector asPoint, a unique string)
          slot 4 -> #x:y:
          slot 5 -> #x
          slot 6 -> #y


i.e. a method is a structured object consisting a vector of bytecodes
and some literals referenced by the bytecode.


The class Point then looks like
          1st inst var superclass -> the class ArithmeticValue
          2nd ist var methodDict -> a dictionary that includes the entry
                                                                #+ -> the method above


            ...
            5th inst var instVarNames -> an array of 'x' 'y', the names of
Point's inst vars, x being the 1st slot and y being the 2nd slot.


Now the bytecode for Point>>#+ might look like:


normal CompiledMethod numArgs=1 numTemps=1 frameSize=12


literals: (#asPoint {Point} #x:y: )


1 <10> push local 0
2 <70> send asPoint
3 <4D> store local 1; pop
4 <35> push Point
5 <00> push inst 0
6 <11> push local 1
7 <F0 25> send x
9 <A0> send +
10 <01> push inst 1
11 <11> push local 1
12 <F0 26> send y
14 <A0> send +
15 <92> send x:y:
16 <65> return


So in Smalltalk the bytecode is embedded in a fully reflective object
system where bytecoded methods themselves are objects that respond to
messages.


Read Smalltalk-80: The Language and its Implementation. The
implementation part is on line.


>
> Any thoughts or information would be greatly appreciated.
> [It's the same as any time you want to do dynamic linking. You store a
> symbol table along with the stuff you want to link to. -John


--
_______________,,,^..^,,,____________________________
Eliot Miranda Smalltalk - Scene not herd

Return to the comp.compilers page.
Search the comp.compilers archives again.