Why Bytecode?

[Maneesh Yadav]

Eric W. Biederman wrote:

> >>>>> "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.
> >>
>

OK, but I really never got to like the idea of interpeting, besides the only reason java
is partially interpeted is for security reasons for applets no? On a usable system, the
programs would have to be compiled to provide perfomance, IMHO.  What about a system
with a sort of  transparent 2 way compiler, that would compile HLL into native code and
upon export to another system, could invert it to the HLL and be automatically
recompiled on the target?

> 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.
>

But aren't jump instructions and the like a part of the bytecode?  And thus dictate the
order in which they are exectued and thus performance?

> >> 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.
>

I'm with you, but as long as money is around, the rest of the world isn't.

> 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