What exactly is bytecode?

Question

Is byte code an intermediate form of code between assembly code and machine code? And is bytecode the same as object code?

This is what I think - High level language->Assembly language->Machine code/Object code (0s and 1s. different for different CPUs)

Is it like this? High level language->Assembly language-> Byte code(will be taken care of by virtual machine, which will convert it into machine code) -> Machine code

I've read this - SO- bytecode vs assembly language code , but need to understand it better

Answer 1

Officially, there is no such thing as "bytecode" (at least not in Java) -- it's simply "code". (You won't find "bytecode" anywhere in the Java Virtual Machine Specification.)

But informally it's the term applied to the virtual machine "instructions" in the "Code" attribute of a Java method definition inside a Java .class file. And the term is also applied (probably with no more "rigor") to the virtual machine instructions of several other languages such as C++.

The concept of virtual machine instructions is generally agreed to have originated with the "p-code" of UCSD Pascal and a few related early Pascal language implementations. Basically, these are a form of compiler "intermediate language" that can be interpreted directly by a "virtual machine", vs requiring an additional compile step to convert to native machine code. Typically, a virtual machine instruction set is designed to (as much as possible) be "machine independent" and not specific to any particular operating system or hardware instruction set.

Bytecode instructions are generally simple actions on a "stack architecture". The stack architecture is convenient because it's easy to compile to, allows "instructions" to be very simple, is easy to interpret, and is a convenient "source" for subsequent optimization and code generation steps in a regular compiler scenario. (A notable exception is the Android Dalvik virtual machine, with an instruction set that is not a stack archtecture, but rather a register-based architecture.)

In Java, it is most common for a Java program to be initially "interpreted", with the bytecodes being "executed" by the JVM's interpreter. Then, if and when individual methods are determined to be "hot" (highly used) the individual methods are compiled using a "just-in-time compiler" (JITC) into the instruction set of the "target" hardware. Other language implementations may stay wholly interpreted or may immediately translate to machine instructions.

Answer 2

Bytecode is nothing more than an instruction set for a VM. The implementation of this may or may not involve JIT to machine code. Often, it does not. The official Lua implementation, for example, interprets bytecode rather than converting it to machine code. .NET and Java implementations almost always compile "hot paths" into machine code for more efficient execution. Ultimately, this is a VM implementation detail and has nothing to do with bytecode itself, which is just instructions for the VM.

Object code, AFAIK, is always machine code.

Answer 3

Java Platform: High level language -> Byte code Byte code is executed by VM such as JVM

.Net platform: High level language -> CIL (Common Intermediate Language) ---Just in time compiled (JIT)---> Native machine code

Native compilation: High level language -> Object code (native machine code) ---linked to--> executable (native machine code) Linking takes care of fixing the address references of variables amongst other things.

Answer 4

Yes, Bytecode is pre-machine code; which in turn taken care by the virtual runtime and gets converted to machine code (into 0/1). In case of java it's bytecode and in case of .NET it's IL/CIL.

Taken from Here

Bytecode, also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter. Unlike human-readable source code, bytecodes are compact numeric codes, constants, and references (normally numeric addresses) which encode the result of parsing and semantic analysis of things like type, scope, and nesting depths of program objects. They therefore allow much better performance than direct interpretation of source code.