Javascript bytecode

[Rob T]

On Wednesday, 19 December 2012 at 01:09:14 UTC, F i L wrote:
> Without bytecode, the entire compiler becomes a dependency of a 
> AOT/JIT compiled program.. not only does bytecode allow for 
> faster on-site compilations, it also means half the compiler 
> can be stripped away (so i'm told, i'm not claiming to be an 
> expert here).
>
> I'm actually kinda surprised there hasn't been more of a 
> AOT/JIT compiling push within the D community.. D's the best 
> there is at code specialization, but half of that battle seems 
> to be hardware specifics only really known on-site... like SIMD 
> for example. I've been told many game companies compile against 
> SIMD 3.1 because that's the base-line x64 instruction set. If 
> you could query the hardware post-distribution (vs 
> pre-distribution) without any performance loss or code 
> complication (to the developer), that would be incredibly idea. 
> (ps. I acknowledge that this would probably _require_ the full 
> compiler, so there's probably not be to much value in a 
> D-bytecode).
>
> The D compiler is small enough for distribution I think (only 
> ~10mb compressed?), but the back-end license restricts it right?

I'm not claiming to be an expert in this area either, however it 
seems obvious that there are significant theoretical and 
practical advantages with using the bytecode concept.

My understanding is that with byte code and a suitable VM to 
process it, one can abstract away the underlying high-level 
language that was used to produce the byte code, therefore it is 
possible to use alternate high level languages with front-ends 
that compile to the same common bytecode instruction set. This is 
exactly the same as what is being done with the D front end, and 
other front ends for the GCC, except for the difference that the 
machine code produced needs a physical cpu to process it, and 
there is no machine code instruction set that is common across 
all architectures.

Effectively, the bytecode serves as the common native machine 
code for a standardized virtualized cpu (the VM) and the VM can 
sit on top of any given architecture (more or less).

Of course there are significant execution inefficiencies with 
this method, however bytecode can be compiled into native code - 
keeping in mind that you did not have to transport whatever the 
high level language was that was compiled into the byte code for 
this to be possible.

So in summary, the primary purpose of byte code is to serve as an 
intermediate common language that can be run directly on a VM, or 
compiled directly into native machine code. There's no need to 
transport or even know what language was used for producing the 
byte code.

As a reminder, this is what "my understanding is", which may be 
incorrect in one or more areas, so if I'm wrong, I'd like to be 
corrected.

Thanks

--rt