MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]
Re: MOO into C
>dg@dcs.st-and.ac.uk writes:
(a load of gibberish)
Sorry about that; I Have Been Corrected By Pavel, and am repentant. :)
I've jsut done some investigation about bracket positioning using
disassemble(). The reason why I thought that it wasn't decompiled was by
groping through a lot of disassembled code and seeing arithmetic expressions
crunched down so far by the compiler that I didn't think that it would be
possible to decompile them to the original expression.
1 + 1 + 1 compiles to:
NUM 1
NUM 1
NUM 1
ADD
ADD
and 1 + (1 + 1) compiles to
NUM 1
NUM 1
ADD
NUM 1
ADD
without using opcode tricks, and the decompiler manages to preserve brackets.
I'm impressed, I really am.
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.
For example, this:
a = 1;
b = 1 + 1 + 1;
starts out as:
NUM 1
PUT a
POP
NUM 1
...
If the optimiser could noticed that it could remove some code, producing:
NUM 1
PUT a
...
then this would probably decompile sanely to:
b = (a = 1) + 1 + 1;
A legal program, but not one a human would write. 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?
BTW, what do the asterisks in the disassembled output mean?
--
------------------- http://www-hons-cs.cs.st-and.ac.uk/~dg --------------------
If you're up against someone more intelligent than you are, do something
totally insane and let him think himself to death. --- Pyanfar Chanur
---------------- Sun-Earther David Daton Given of Lochcarron ------------------
Follow-Ups:
References:
Home |
Subject Index |
Thread Index