Re: Dynamic Evaluation & Precompiled Bytecode

Eliot Miranda <eliotm@pacbell.net>
5 Mar 2006 02:19:56 -0500

          From comp.compilers

Related articles
Dynamic Evaluation & Precompiled Bytecode acampbellb@hotmail.com (Avatar) (2006-02-11)
Re: Dynamic Evaluation & Precompiled Bytecode anton@mips.complang.tuwien.ac.at (2006-02-11)
Re: Dynamic Evaluation & Precompiled Bytecode eliotm@pacbell.net (Eliot Miranda) (2006-03-05)
| List of all articles for this month |

From: Eliot Miranda <eliotm@pacbell.net>
Newsgroups: comp.compilers
Date: 5 Mar 2006 02:19:56 -0500
Organization: SBC http://yahoo.sbc.com
References: 06-02-079
Keywords: interpreter
Posted-Date: 05 Mar 2006 02:19:56 EST

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


Post a followup to this message

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