Why do programing languages compile to byte code ?

[AFB]

?

 

[FrankSchwab]

What would you prefer them to compile to?

Personally, I've used programming languages that compile to byte code, to machine code, to assembly, to P-code, and probably others if I thought about it.

What was your question again?

/frank

 

[AFB]

Originally posted by: FrankSchwab
What would you prefer them to compile to?

Personally, I've used programming languages that compile to byte code, to machine code, to assembly, to P-code, and probably others if I thought about it.

What was your question again?

/frank

Is it portability ?

 

[jhu]

you may want to elaborate on your question. not every compiler compiles to byte code.

 

[FrankSchwab]

Well, if I understand your clarification, what you are asking is:

Why would someone make a compiler that compiles to byte code rather than to more traditional forms (machine code, assembly, etc).

I think you'd find at least three reasons:
1. Portability.
2. Security
3. Performance.

Portability - compiling to byte code can allow you to create both hardware and OS independent programs. The UCSD P-System did that ages ago, and Java attempts to do it today. It's not clear why .NET does so, other than perhaps to put the fear of God into Intel.

Security - Compiling to byte code allegedly makes it easier to examine a program for security flaws. You can define a relatively simple, easily verified "virtual machine" that your Byte code is targeted at. Byte code can be quickly checked against this model, and good code executed. It's a whole lot harder to check x86 machine code for security flaws, especially when different processors (and different mask revisions within processor types) have different "errata" that might affect program behavior.

Performance - As Java, Basic, and .Net demonstrate, Byte-code does not execute as fast as native code.

The first time you run through the code, or when run through a dumb run-time interpreter.

However, smart run-time interpreters can do a "just-in-time" compilation, meaning that the first time byte code is executed, it gets recompiled to native code. This means that, after startup and the first pass through the program, byte-code can theoretically be just as fast as native code.

In addition, VERY smart run-time interpreters can go one step past this. They can "profile" the code as it's executing, and optimize the compiled code to speed it up. For example, a compiler can't know how many iterations a program is going to make through a loop, so generates generic loop code. The run-time interpreter can profile the code as it executes, and notice that 98 of the last 100 times through the loop, the code exited the loop after the first or second iteration - it can then generate new code optimized for this situation. In this situation, ignoring the startup time and the first 100 iterations through the particular loop (and the profiling time, and the recompilation time), the Byte code form of the program can be significantly FASTER than the code compiled by a conventional compiler.

 

[Cogman]

Speed is definitly a key feature. The computer has to be able to read the code and it cannot read a simple statment like

If(1 != 0){
echo "The world is comming to an end";
}
else{
echo "All is well with the universe";
}

because the computer is based on 1's and 0's, it has to read things in the form of 1's and 0's. everything, even scripts, are interperted and changed into those 1's and 0's.

 

[AFB]

Originally posted by: FrankSchwab
Well, if I understand your clarification, what you are asking is:

Why would someone make a compiler that compiles to byte code rather than to more traditional forms (machine code, assembly, etc).

I think you'd find at least three reasons:
1. Portability.
2. Security
3. Performance.

Portability - compiling to byte code can allow you to create both hardware and OS independent programs. The UCSD P-System did that ages ago, and Java attempts to do it today. It's not clear why .NET does so, other than perhaps to put the fear of God into Intel.

Security - Compiling to byte code allegedly makes it easier to examine a program for security flaws. You can define a relatively simple, easily verified "virtual machine" that your Byte code is targeted at. Byte code can be quickly checked against this model, and good code executed. It's a whole lot harder to check x86 machine code for security flaws, especially when different processors (and different mask revisions within processor types) have different "errata" that might affect program behavior.

Performance - As Java, Basic, and .Net demonstrate, Byte-code does not execute as fast as native code.

The first time you run through the code, or when run through a dumb run-time interpreter.

However, smart run-time interpreters can do a "just-in-time" compilation, meaning that the first time byte code is executed, it gets recompiled to native code. This means that, after startup and the first pass through the program, byte-code can theoretically be just as fast as native code.

In addition, VERY smart run-time interpreters can go one step past this. They can "profile" the code as it's executing, and optimize the compiled code to speed it up. For example, a compiler can't know how many iterations a program is going to make through a loop, so generates generic loop code. The run-time interpreter can profile the code as it executes, and notice that 98 of the last 100 times through the loop, the code exited the loop after the first or second iteration - it can then generate new code optimized for this situation. In this situation, ignoring the startup time and the first 100 iterations through the particular loop (and the profiling time, and the recompilation time), the Byte code form of the program can be significantly FASTER than the code compiled by a conventional compiler.

Excellent post, have a
:beer: on me. 🙂😀