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