Why Bytecode?

[Fare Rideau]

Dear Tunesmiths,

>>: Maneesh Yadav
>: Eric Biederman

>> OK, this may be a stupid comment, but I can't figure out a good answer.
>> Why is that VM's like java impliment their thing with a universal
>> bytecode?
>
> Efficiency, and portability.  A byte code is a no brainer to
> interpret, just do a switch on the byte code, and go to the right
> place to interpret that.
>
I agree with the latter, but not with the former.
Bytes are neither efficient nor portable, unless your measure
of efficiency is time taken to code the interpreter:
bytecodes are too low-level for good compilation,
not high-level enough to amortize interpretation overhead;
too small to allow good/easy expansion,
not suited to good compression.
Plus modern architectures may make extracting bytes from memory inefficient
(especially on word-addressable architectures,
especially if you have to colesce non-aligned data back into words,
especially when word size is not multiple of 8).

All the serious experiments done show that bytecode just doesn't buy it
in terms of either performance or portability.
See how OCaml gained a factor 2 (approx.) in performance on several
architectures by using wordcodes, where Caml-Light used to use bytecodes.
Bytecodes can be justified indeed, in either by quick-and-dirty approaches,
or when runtime memory saving are needed, because it's expensive
(embedded software, OpenBoot PROM), or to avoid swapping (see clisp vs ACL).
Even then a judicious choice of bytecode is not easy,
unless you have a set of tools to consistently modify the bytecode system
and retarget the bytecode generators (in an optimizing way).

> Also basic optimizations can be done ahead of time.
Bytecode doesn't make that easier than any representation!
Just any code representation allows for peephole optimization;
bytecode tend to be too low-level and make high-level optimizations
impossible in the backend.

> Besides I haven't seen a `universal' bytecode.
What do you mean by "universal"?
The JVM claims to be. The Caml-light VM has long been.


>> Why not concentrate on a VM with a readable language with a JIT and save
>> space by leaving it up to a compression algo.?
>> In order to prevent the code stealing, mangled sources could be used...
Yup. All that's precisely exactly what Juice does
http://www.tunes.org/~tunes/doc/Review/VMs.html#Juice

> Code's copyrighted so why do you need to worry about code stealing?
I also agree; still code mangling will be a "plus" to convince paranoïds
to use Tunes anyway.

>> I realize that a bytecode is good since it resembles a processers
>> instruction set nad is small.  But why restrict a language to only work
>> with today's processing paradigms (who knows what's next).  Surely a
>> good HLL leaves more room for the future.
> It's expedient, simple, and well tested.  When that future comes you
> upgrade your virtual machine.
It might be expedient, but it's neither particularly simple
(try to be simpler than a LISP interpreter!), nor particularly well-tested
(why should bytecodes be intrinsically better tested than anything???).

And we all know that if you make your bytecode a standard way to
transport code (see the JVM), then you're casting into stone your
bytecode specification and you can't upgrade. A high-level representation
makes upgrade much easier.

Surely, if the bytecode is "only used internally",
then you can upgrade without any problem;
but then, what's the use for a bytecode anyway?


>> Doesn't bytcode just put an unessecary step in between
>> idea-> language->program?
> No.  It just specifies the form.
Yes, it is, in the above diagram, where programs are executed directly.
But remember that bytecodes and the like are to be used to transport
programs in a portable way; a framework of standard transport representations
is necessary here; the fact that these representation be bytecode is
unnecessary, and a bad idea. Again, see the Juice way of doing things.


PS: again, this is all my opinion. Feel free to differ.
  Running code will decide.
PPS: Juice does run already, and compares positively to the much-hyped JVM.
  I still have to d/l it.

== Faré -=- (FR) François-René Rideau -=- (VN) Уng-Vû Bân -=- rideau@ens.fr ==
Join a project for a free reflective computing system! | 6 rue Augustin Thierry
TUNES is a Useful, Not Expedient System.               | 75019 PARIS     FRANCE
http://www.eleves.ens.fr:8080/home/rideau/Tunes/ -=- Reflection&Cybernethics ==