Re: MOO into C

• Date: Wed, 24 Jul 1996 09:14:19 PDT
• From:
  Pavel Curtis <pavel@parc.xerox.com>
• 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

• Re: MOO into C
• From: dg@dcs.st-and.ac.uk

• 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