On 21.12.2012 11:28, Walter Bright wrote:
On 12/21/2012 12:37 AM, Rainer Schuetze wrote:
On 21.12.2012 08:02, Walter Bright wrote:
On 12/20/2012 10:05 PM, deadalnix wrote:
No you explained that java's bytecode doesn't solve that problem.
Which is quite
different.
I did, but obviously you did not find that satisfactory. Let me put it
this way:
Design a bytecode format, and present it here, that is CTFEable and is
not able to be automatically decompiled.
Sorry, can't resist: How about feeding the x86 machine byte code
(including some
fixup information) into an interpreter? Maybe not realistic, but a
data point in
the field of possible "byte codes". The interpreter might even enjoy
hardware
support ;-)
Not going to work, as CTFE needs type information. CTFE needs to
interact with the current symbols and types in the compilation unit.
Just think about what you'd need to do to get CTFE to read the object
file for a module and try to execute the code in it, feeding it data and
types and symbols from the current compilation unit? Consider:
add EAX,37
mov [EAX],EBX
what the heck is EAX pointing at?
I think you don't need to care. The CPU can execute it as well without
type information.
If the data layout of the interpreter values is the same as for the
interpreted architecture, all you need to know is the calling convention
and the types of the arguments to the function to be executed and the
return type.
I'd intercept calls to other functions because the interpreter might
want to replace them with non-native versions (e.g. new or functions
where the source code exists). The types of the data passed when
executing these calls are known as well.
