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
