Why Bytecode?
Eric W. Biederman
ebiederm+eric@npwt.net
06 Feb 1998 19:49:03 -0600
>>>>> "MY" == Maneesh Yadav <97yadavm@scar.utoronto.ca> writes:
MY> Eric W. Biederman wrote:
>> >>>>> "MY" == Maneesh Yadav <97yadavm@scar.utoronto.ca> writes:
>>
>> 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.
>>
MY> I find it hard to believe that writing an java interpeter is as easy as writing
MY> a big switch statement in a loop.
It is, but the dispatch code for each byte code is that simple.
No parsing, or anything hard to figure out what you are supposed to do.
>> Also basic optimizations can be done ahead of time.
>>
MY> Certain optimizations that work on one processers may not optimize well on
MY> another, past the algorithm level, (take branch prediction for instance on a 486
MY> pentium and ppro)
It's more like constant propogation and removal of some redundancies,
a la peephole optimization.
It's bytecode not machine specific.
If you want to see an example see the emacs lisp compiler.
>> Besides I haven't seen a `universal' bytecode.
>>
MY> Why not concentrate on a VM with a readable language with a JIT and save
MY> space by leaving it up to a compression algo.?
>>
MY> In order to prevent the code stealing, mangled sources could be used...
>>
>> Code's copyrighted so why do you need to worry about code stealing?
>>
MY> Oh yeah, I forgot it's a perfect world with perfect programmers :-)....
Well actually I think the whole issue of people worry about their code
is a little silly. I'm more in the software as a service camp.
MY> I realize that a bytecode is good since it resembles a processers
MY> instruction set nad is small. But why restrict a language to only work
MY> with today's processing paradigms (who knows what's next). Surely a
MY> good HLL leaves more room for the future.
>>
>> It's expedient, simple, and well tested. When that future comes you
>> upgrade your virtual machine.
>>
MY> That's what I'm saying we could possibly prevent by not using a bytecode, no one
MY> likes to upgrade unless they have to....
You can also use a compiler that will translate one bytecode into
another, and with version numbers you can support both. Bytecode
simply optimizes the common case.
MY> Doesn't bytcode just put an unessecary step in between
MY> idea-> language->program?
>>
>> No. It just specifies the form.
>>
MY> Couldn't that be done more elegantly in an HLL?
It is much easier to agree what basic primitives a computer
instruction set needs versus, what a universal high level language
needs.
In tunes we keep wanting to program in the HLL you would need but we
haven't written it yet :)
Eric