Why Bytecode?

[Eric W. Biederman]

>>>>> "MY" == Maneesh Yadav <97yadavm@scar.utoronto.ca> writes:

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

MY> OK, but I really never got to like the idea of interpeting, besides the only reason java
MY> is partially interpeted is for security reasons for applets no? On a usable system, the
MY> programs would have to be compiled to provide perfomance, IMHO.

Except for _very_ performance intensive applications byte code, should work fine.
Especially if it has it's most common libraries in native code.

Again see emacs.  I have several large applications, that I run in
emacs all of which are compiled into bytecodes.  And never suffer
significant performance problems.a

MY> What about a system
MY> with a sort of  transparent 2 way compiler, that would compile HLL into native code and
MY> upon export to another system, could invert it to the HLL and be automatically
MY> recompiled on the target?

Inveresion to HLL (except by storage) is quite nontrivial.

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

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

But in bytecode you can't overlap instructions, as instructions all
execute in order.  The giant switch approach is actually pretty bad
from a branch prediction standpoint.  

But generally while branch prediction and other methods that extract
parallelism form modern processors are increassingly important.  It
isn't an issue you can address at all in bytecode.

>> 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'm with you, but as long as money is around, the rest of the world isn't.

There are two ways software can be sold.
A) here is a piece of shrink wrapped software that might do what you
want.
B) I will write programs for you to do what you want, and I will
maintain and service them.

For different types of software different models are appropriate.
Although there are times, that microsoft and others upgrade there
software often (in model A), where modle B would be more appropriate.

In model B you are generally paid for your time writting the code,
so you have been paid by the time the code is delivered.  The
copyright is a nonissue.

What is a challenge is to write and maintain code, as a service where
no one client has the money to pay you for all of your time.

I also write code for fun and GPL it, but that's another matter.

The GPL was written very carefully so that it can be used
comercially.  And the source is just a feature of your product.

Eric