[Prev][Next][Index][Thread]

# Re: MOO into C

- Date: Wed, 24 Jul 1996 09:14:19 PDT
- From:
- Cc: moo-cows@parc.xerox.com
- In-reply-to: dg@dcs.st-and.ac.uk's message of "Wed, 24 Jul 1996 08:10:17 PDT" <18141.9607241510@dufftown.dcs.st-andrews.ac.uk>

    dg@dcs.st-and.ac.uk writes:
    > >The only downside is that optimized code wouldn't decompile back into MOO
    > >source code.
    >
    > It never is decompiled. The verb source is stored seperately from the
    > byte-compiled version, in text form. Try disassembling some byte-compiled
    > code one day and try decompiling it... it's just not possible (easily).

    This isn't true; the server throws away the source code after compilation and
    regenerates it from the bytecodes by decompilation every time it's needed.  The
    decompilation process isn't precisely simple, but it certainly isn't
    impossible; take a look at decompile.c.  The compiler does a number of things
    to make it straightforward, like using different opcodes for the same operation
    depending on which syntactic construct is involved (e.g., the "test" opcodes
    for IF vs. ELSE-IF vs. WHILE vs. "x ? y | z") and using special opcodes to
    distinguish semantically equivalent operations that are written in multiple
    ways (e.g., "PUSH 0; RETURN" vs. "RETURN0" vs. "DONE" for "return 0;"
    vs. "return;" vs. falling off the end of the verb).  One of the more
    interesting parts of the upgrade to 1.8.0 was rewriting the decompiler from
    scratch; it was kind of fun to finally find the right deep structure for the
    problem that makes the solution easily understood.

    	Pavel

Follow-Ups:

- Re: MOO into C

- From: dg@dcs.st-and.ac.uk

References:

- Re: MOO into C

- From: dg@dcs.st-and.ac.uk

- Prev: Re: MOO into C
- Next: Re: MOO into C
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index