MOO-cows Mailing List Archive


Re: MOO into C

> 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

and 1 + (1 + 1) compiles to

	NUM 1
	NUM 1
	NUM 1

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
	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?

------------------- --------------------
   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