Javascript bytecode

[Rainer Schuetze]

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.