MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
Re: MOO into C
At 09:40 AM 7/24/96 PDT, dg@dcs.st-and.ac.uk wrote:
>without using opcode tricks, and the decompiler manages to preserve brackets.
>I'm impressed, I really am.
Before optmizations, any decompiler should be able to reproduce the original
AST from the byte codes. After optimizations, it's another story (as you
mention below).
I suggest you pick up a book on compiler construction. There are a number
of them widely avaiable. The computer section at any decent sized bookstore
should carry a bunch of them (Borders, out here in Chicago, does).
>Is it possible to write a program in byte-code that won't decompile? This
>discussion was sparked off by someone suggesting that a byte-code optimiser
>would be useful, but optimised code wouldn't decompile properly (which was
>where I put my foot in it). If *all* (meaningful) programs will decompile,
>then *let* the optimiser mangle the code. You may get some interesting
>programs when decompiling, though.
If all meaningful programs will decompile, does that mean they are
reversable and that a decompiled optmized method will recompile into a
usable form?
>then this would probably decompile sanely to:
>
> b = (a = 1) + 1 + 1;
>
>A legal program, but not one a human would write.
I write code like this all the time. I've been known to do:
if (valid(object = (su = $string_utils):match_object(the_string)))
>Things would get even more
>complicated if the optimiser could identify chunks of independent code and
>rearrange them to allow this. b = (a = 1) + (b = 1) + (c = 1), anybody?
I hope these are only examples of optmiziations, since saving a stack
manlipulation operation isn't much in terms of savings.
>BTW, what do the asterisks in the disassembled output mean?
The astericks flag which bytecodes cause a decrement of the tick counter.
Andy.
Follow-Ups:
Home |
Subject Index |
Thread Index