On Friday, 21 December 2012 at 17:08:28 UTC, Simen Kjaeraas wrote:
> On 2012-00-21 12:12, Max Samukha <maxsamukha@gmail.com> wrote:
>
>> On Friday, 21 December 2012 at 10:30:21 UTC, Walter Bright wrote:
>>> On 12/21/2012 2:13 AM, Max Samukha wrote:
>>>> What Walter is wrong about is that bytecode is entirely pointless.
>>>
>>> I'll bite. What is its advantage over source code?
>>
>> It is not about bytecode vs source code. It is about a common platform-independent  intermediate representation for multiple languages. JS is such a representation in the browsers and it is widely used. It it entirely pointless? I am not convinced it is.
>
> But Walter has said that for exactly this purpose, bytecode is useful.

Really? He sounded like the whole world should repent for using IRs. Maybe I misunderstood.

> What he's said is that in the case proposed (using bytecode instead of
> source code for CTFE), bytecode offers absolutely no advantage over
> source.
>
> Now can we move on? It's been said so many times now, and we all know
> Walter is not a pushover. If nobody can present irrefutable, solid,
> peer-reviewed, and definite proof that bytecode has significant
> advantages over source code for the purpose of CTFE, such an
> implementation will never be done, and the world will be better off
> for it.

I am not arguing that.

On Friday, 21 December 2012 at 07:03:13 UTC, 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.

Optimized LLVM bytecode look like a good candidate for the job. Note that I'm not suggesting this as a spec, but as an example of possible solution.

> Optimized LLVM bytecode look like a good candidate for the job. Note that I'm not suggesting this as a spec, but as an example of possible solution.

It's true that it couldn't be automatically decompiled to something equivalent to the original D source, but it does contain type information. Its human readable form (llvm assembly language) is easier to understand than assembly.

On 12/21/2012 3:52 AM, Rainer Schuetze wrote:
> 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.

CPU instructions are as unportable as you can get. All type information is lost, as well as all information as to where the values for things come from. Hence, such a format has dependencies on every module and switch it was compiled with, dependencies that cannot be accounted for if they change.

It cannot be inlined, no inferences can be made as to purity, and it's hard to see how CTFE could determine if a particular path through that code is supported or not by the CTFE.

In fact, it is useless as a means of importing module information - you might as well just link to that object code at link time.

On 12/21/2012 12:07 PM, jerro wrote:
>> Optimized LLVM bytecode look like a good candidate for the job. Note that I'm
>> not suggesting this as a spec, but as an example of possible solution.
>
> It's true that it couldn't be automatically decompiled to something equivalent
> to the original D source, but it does contain type information. Its human
> readable form (llvm assembly language) is easier to understand than assembly.

I haven't looked at the format, but if it's got type information, that goes quite a long way towards supporting automatic decompilation.

On Friday, 21 December 2012 at 20:08:00 UTC, jerro wrote:
>> Optimized LLVM bytecode look like a good candidate for the job. Note that I'm not suggesting this as a spec, but as an example of possible solution.
>
> It's true that it couldn't be automatically decompiled to something equivalent to the original D source, but it does contain type information. Its human readable form (llvm assembly language) is easier to understand than assembly.

Once the optimizer is passed, a lot of it is lost. It is easier to understand than pure x86 assembly, but it is clearly opaque.