from jsopcodes back to JavaScript

[George-36]

Is there a "decompile" function already existing in the current
spidermonkey's code base that translate a jsopcode program back to
JavaScript program? In other words, I am looking for a utility which
inverts the JS shell command dis().

Thanks,
Yan
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

[Jason Orendorff-2]

On 10/27/2009 04:50 PM, Yan Huang wrote:
> Is there a "decompile" function already existing in the current
> spidermonkey's code base that translate a jsopcode program back to
> JavaScript program?

What's a jsopcode program? Where have you found such a thing?

 > In other words, I am looking for a utility which
 > inverts the JS shell command dis().

You want to convert the textual output of dis() back to a JavaScript
function?

The decompiler already exists:

https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_DecompileFunction

You would need an assembler to parse the dis() output. It would be
possible to hack that together out of pieces of imacro_asm.js.in. Then
you would need to turn that into a Function, which I think can be done
from JS, in Narcissus. But I'm still not sure this is what you really
want to do.

-j


_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

[George-36]

On Oct 29, 4:51 pm, Jason Orendorff <jorendo...@...> wrote:
> On 10/27/2009 04:50 PM, Yan Huang wrote:
>
> > Is there a "decompile" function already existing in the current
> > spidermonkey's code base that translate a jsopcode program back to
> > JavaScript program?
>
> What's a jsopcode program? Where have you found such a thing?

For example, at spidermonkey's JS shell, type
js> function f(x){return x;}
js> dis(f)
main:
00000:  getarg 0
00003:  return
00004:  stop

Source notes:
js>

the three lines of jsopcodes is what I mean opcode program
corresponding to the identity function f.
I was asking what is an elegant way to implement a Decompiler, so that
given
    getarg 0
    return
    stop
as input, it outputs
    function f(x) {return x;}
or an equivalent JS function.

Thanks,
-- Yan

>  > In other words, I am looking for a utility which
>  > inverts the JS shell command dis().
>
> You want to convert the textual output of dis() back to a JavaScript
> function?
>
> The decompiler already exists:
>
> https://developer.mozilla.org/en/SpiderMonkey/JSAPI_Reference/JS_Deco...
>
> You would need an assembler to parse the dis() output. It would be
> possible to hack that together out of pieces of imacro_asm.js.in. Then
> you would need to turn that into a Function, which I think can be done
> from JS, in Narcissus. But I'm still not sure this is what you really
> want to do.
>
> -j

_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

[Jason Orendorff-2]

On 10/30/2009 12:05 AM, Yan Huang wrote:
> I was asking what is an elegant way to implement a Decompiler, so that
> given
>      getarg 0
>      return
>      stop
> as input, it outputs
>      function f(x) {return x;}
> or an equivalent JS function.

That seems like a wrong thing to want to do. SpiderMonkey's bytecode
instruction set is not a stable, public interface. It changes over time.

Also, the output of dis() might not be sufficient to reproduce the
source code. Besides bytecode instructions, SpiderMonkey functions also
contain source notes, try notes, block objects, and other stuff.

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

[George-36]

On Oct 30, 5:49 pm, Jason Orendorff <jorendo...@...> wrote:

> On 10/30/2009 12:05 AM, Yan Huang wrote:
>
> > I was asking what is an elegant way to implement a Decompiler, so that
> > given
> >      getarg 0
> >      return
> >      stop
> > as input, it outputs
> >      function f(x) {return x;}
> > or an equivalent JS function.
>
> That seems like a wrong thing to want to do. SpiderMonkey's bytecode
> instruction set is not a stable, public interface. It changes over time.
>

Yes, I know these opcodes are not open interfaces offered by
spidermonkey. I am trying
to develop research prototypal tools based on spidermonkey. The hope
is that the same
idea could easily be applied to other programming langauges, like
Java, and C/C++.

> Also, the output of dis() might not be sufficient to reproduce the
> source code. Besides bytecode instructions, SpiderMonkey functions also
> contain source notes, try notes, block objects, and other stuff.
>

Can you explain more about what is "source notes", "try notes", "block
objects" and "other stuff",
or suggest some pointers about the information?

Thanks,
Yan Huang
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

[John J Barton]

Yan Huang wrote:

> On Oct 30, 5:49 pm, Jason Orendorff <jorendo...@...> wrote:
>> On 10/30/2009 12:05 AM, Yan Huang wrote:
>>
>>> I was asking what is an elegant way to implement a Decompiler, so that
>>> given
>>>      getarg 0
>>>      return
>>>      stop
>>> as input, it outputs
>>>      function f(x) {return x;}
>>> or an equivalent JS function.
>> That seems like a wrong thing to want to do. SpiderMonkey's bytecode
>> instruction set is not a stable, public interface. It changes over time.
>>
> Yes, I know these opcodes are not open interfaces offered by
> spidermonkey. I am trying
> to develop research prototypal tools based on spidermonkey. The hope

I suggest that a great way to start is to implement an API that exposes
the result of the dis() operation to Javascript code.  This would allow
you to write tools for analyzing Javascript in Javascript, thereby
gaining a dramatic speed up in exploration time and simple access to
user interface support. It would also allow Firebug and Chromebug to
show the bytecodes so we could create tools for understand how the
bytecodes arise from the source.

> is that the same
> idea could easily be applied to other programming langauges, like
> Java, and C/C++.

Hopefully after you begin work on this project you will see how this
goal is not important compared to developing ways to improve Javascript
and future dynamic languages.

>
>> Also, the output of dis() might not be sufficient to reproduce the
>> source code. Besides bytecode instructions, SpiderMonkey functions also
>> contain source notes, try notes, block objects, and other stuff.
>>
>
> Can you explain more about what is "source notes", "try notes", "block
> objects" and "other stuff",
> or suggest some pointers about the information?

Yes we need more documentation on the structure of JS compilation output.

>
> Thanks,
> Yan Huang
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine

[Jason Orendorff-2]

On 10/31/2009 12:05 PM, John J. Barton wrote:
> Yan Huang wrote:
>> Can you explain more about what is "source notes", "try notes", "block
>> objects" and "other stuff",
>> or suggest some pointers about the information?
>
> Yes we need more documentation on the structure of JS compilation output.

I'm not sure this is a good idea, but you're welcome to the information.
Drop by #jsapi on IRC if you have any questions.

Recall that even a regular compiler for a language like C++ or Java
doesn't just produce code-- the output is a binary file that contains
both code and data. The data includes string literals and static tables
of numbers that appeared in the source code, but also information needed
by the linker (e.g. method names and signatures), the debugger (variable
names, line numbers), and the language runtime (C++ RTTI, Java
reflection, exception handler tables).

Similarly, the JS compiler produces JSScripts that contain bytecode and:

* Basic metadata the interpreter needs in order to execute the script -
such as the amount of stack space the script needs.

* String literals and numbers that appear in the code. (Each JSOP_STRING
and JSOP_DOUBLE instruction contains an index into the script's table of
strings.)

* Property names used by GETPROP etc. instructions in the script. (Each
of those instructions contains an index into the script's table of
"atoms", which in this context means property names.)

* upvars - Certain accesses to variables in enclosing functions use some
numbers that are stored in a small separate table, not embedded in the
bytecode itself. (I don't know why not.)

* Block objects - In short, Block objects store let-variables (in cases
where we can't optimize them away).

* RegExp objects - Regular expressions in the source code become RegExp
objects attached to the script.

* Functions objects - Similarly a JSScript contains pointers to the
compiled version of each function it directly contains.

* Try notes - Information used only during stack unwinding when an
exception is thrown. I think it just tells the range of bytecodes
covered by each try block, and what to do when an exception occurs
within that range of code.

* Debugger information, such as argument and variable names, and file
and line number information.

* Source notes - Metadata used for the sole purpose of reconstructing
the script or function's source code from its JSScript. (See the
JS_Decompile* API functions and Function.prototype.toString.)

* The JavaScript version under which the script was compiled. Apparently
run-time behavior may vary slightly depending on the version, and in
those cases the interpreter needs to look this up. I don't remember any
details.

* Security principals.

And there might be something I'm forgetting. Hope this helps!

-j
_______________________________________________
dev-tech-js-engine mailing list
dev-tech-js-engine@...
https://lists.mozilla.org/listinfo/dev-tech-js-engine