2 added 1167 characters in body
source | link

Whether it's statically translated intoApart from machine code, dynamicallythere is no programming language in existence which executes directly on hardware, in the sense that you can't feed it the literal source text. All real implementations must translate the source program into the language of the "machine".

For some implementations, it's translated statically. We usually call these implementations "compiled". For others, or JITit's translated into some intermediate form, which is irrelevantthen translated dynamically as the program is run. We usually call these implementations "interpreted". There is a Ccontinuum of possibilities between these, and even many modern CPUs do dynamic translation as part of its execution core.

Even when your program is statically compiled long before execution, unless you're writing firmware, it's rare that the compiled code runs directly on the bare metal with nothing supporting it. The operating system provides a virtual machine for user-space programs, often providing such features as the illusion that you have a CPU all to yourself. The illusion of a flat memory space which could be larger than the physical RAM attached to the machine is even called "virtual memory".

On top of that, even when you're programming in C, there is a C virtual machine! It is traditionally referred to as "the C runtime", or CRT for short.

Because C is mostly translated directly into assembly/machine code well ahead of time (on some platforms, there may also be some threaded code, and that can be considered part of the virtual machine), the virtual machine usually only has to handle startup and shutdown.

Startup typically involves setting up the stack and heap; the operating system rarely provides these for you, and it's the job of the programming language to provide these to the programmer. On some platforms there may be some initialisation of signal handling, setting up the "main" thread in a multi-threaded environment, running global constructors on the off chance that the program has been linked to C++ code, handling dynamically linked libraries, or there may be some processing required to set up argc/argv and envp. Finally, CRT transfers control to main.

As for shutdown, many operating systems can kill a process uncleanly, so shutdown doesn't need to do very much. The main thing is to process atexit() calls for the case where the program does exit cleanly.

Whether it's statically translated into machine code, dynamically translated, or JIT translated is irrelevant. There is a C virtual machine. It is traditionally referred to as "the C runtime", or CRT for short.

Because C is mostly translated directly into assembly/machine code (on some platforms, there may also be some threaded code, and that can be considered part of the virtual machine), the virtual machine usually only has to handle startup and shutdown.

Startup typically involves setting up the stack and heap; the operating system rarely provides these for you, and it's the job of the programming language to provide these to the programmer. On some platforms there may be some initialisation of signal handling, setting up the "main" thread in a multi-threaded environment, running global constructors on the off chance that the program has been linked to C++ code, or there may be some processing required to set up argc/argv and envp. Finally, CRT transfers control to main.

As for shutdown, many operating systems can kill a process uncleanly, so shutdown doesn't need to do very much. The main thing is to process atexit() calls for the case where the program does exit cleanly.

Apart from machine code, there is no programming language in existence which executes directly on hardware, in the sense that you can't feed it the literal source text. All real implementations must translate the source program into the language of the "machine".

For some implementations, it's translated statically. We usually call these implementations "compiled". For others, it's translated into some intermediate form, which is then translated dynamically as the program is run. We usually call these implementations "interpreted". There is a continuum of possibilities between these, and even many modern CPUs do dynamic translation as part of its execution core.

Even when your program is statically compiled long before execution, unless you're writing firmware, it's rare that the compiled code runs directly on the bare metal with nothing supporting it. The operating system provides a virtual machine for user-space programs, often providing such features as the illusion that you have a CPU all to yourself. The illusion of a flat memory space which could be larger than the physical RAM attached to the machine is even called "virtual memory".

On top of that, even when you're programming in C, there is a C virtual machine! It is traditionally referred to as "the C runtime", or CRT for short.

Because C is mostly translated directly into assembly/machine code well ahead of time (on some platforms, there may also be some threaded code, and that can be considered part of the virtual machine), the virtual machine usually only has to handle startup and shutdown.

Startup typically involves setting up the stack and heap; the operating system rarely provides these for you, and it's the job of the programming language to provide these to the programmer. On some platforms there may be some initialisation of signal handling, setting up the "main" thread in a multi-threaded environment, running global constructors on the off chance that the program has been linked to C++ code, handling dynamically linked libraries, or there may be some processing required to set up argc/argv and envp. Finally, CRT transfers control to main.

As for shutdown, many operating systems can kill a process uncleanly, so shutdown doesn't need to do very much. The main thing is to process atexit() calls for the case where the program does exit cleanly.

1
source | link

Whether it's statically translated into machine code, dynamically translated, or JIT translated is irrelevant. There is a C virtual machine. It is traditionally referred to as "the C runtime", or CRT for short.

Because C is mostly translated directly into assembly/machine code (on some platforms, there may also be some threaded code, and that can be considered part of the virtual machine), the virtual machine usually only has to handle startup and shutdown.

Startup typically involves setting up the stack and heap; the operating system rarely provides these for you, and it's the job of the programming language to provide these to the programmer. On some platforms there may be some initialisation of signal handling, setting up the "main" thread in a multi-threaded environment, running global constructors on the off chance that the program has been linked to C++ code, or there may be some processing required to set up argc/argv and envp. Finally, CRT transfers control to main.

As for shutdown, many operating systems can kill a process uncleanly, so shutdown doesn't need to do very much. The main thing is to process atexit() calls for the case where the program does exit cleanly.