Run-Time environments

Question

I was reading about Run-Time Environments.
In the Dragon book (2nd ed.) I came across the following presentation:

[To implement abstractions, the] compiler creates and manages a run-time environment in which it assumes its target programs are being executed. This environment deals with a variety of issues such as the layout and allocation of storage locations for the objects named in the source program, the mechanisms used by the target program to access variables…

so I'm getting confused about points highlighted above:

• How does compiler execute the code, it is only supposed to generate the intermediate code right?
• And does it create runtime environment? I mean there's not a virtual machine that the program runs on, it just runs on your computer right? When does it create a runtime environment?
• Isn't memory managed by the operating system? Why is allocation of storage done by the compiler and at what point? Probably what variables are needed and how much may be known by the compiler but, how does it communicate this information to the OS?

Answer 1

For most of these questions, the Runtime Environment as it seems to be described in your book is more easily understood by comparing a low-level language like C, to a VM (Runtime Environment) language like Java.

How does compiler execute the code, it is only supposed to generate the intermediate code right?

Your quote doesn't say the compiler executes the code. It says that it can start up a RTE which takes over. For lower level languages that don't use a VM/RTE, it can signal the OS to begin execution of the program. In either case, this is a hand-off, not the execution itself.

And does it create runtime environment? I mean there's not a virtual machine that the program runs on, it just runs on your computer right? When does it create a runtime environment?

Practically speaking, the interpretation of these terms is largely dependant on the language in question.

All programs run on the OS, which manages access to hardware for running programs.

In a low-level language like C, the Runtime Environment as a concept is arguably indistinguishable from the OS itself. Memory alloc/dealloc requests are made directly from the program to the OS.

In a high-level language like Java (the most commonly references "VM" language), the Runtime Environment as a concept is used loosely to refer to the program that sits between the executing program and the OS. The Java Runtime Environment consists of the Java Virtual Machine (which handles memory management requests to the OS, among other things), some libraries, and utilities.

Isn't memory managed by the operating system? Why is allocation of storage done by the compiler and at what point? Probably what variables are needed and how much may be known by the compiler but, how does it communicate this information to the OS?

Hardware memory address reservation is managed by the OS.

Specifics of the complexity of memory management intervention provided by the RTE is going to be specific to the RTE implementation. Some provide more features than others.

The Java Virtual Machine makes the alloc/dealloc requests to the OS on the behalf of the executing programs. It also has a Garbage Collection cycle which looks for and frees memory reservations that are no longer being used by the program, rather than holding them all until execution halts.

In C, it is the explicit responsibility of the executing program to make these requests to the OS. Memory requested remains reserved until the program halts, or the memory is explicitly released by the program.

Answer 2

(Your question seems to be about concepts and terminology. The meaning of termini depends on context - the quote is from a compiler writers' book. Not only are the authors entitled to a "compiler centric" view of things: that perspective is to be expected.)

There are at least two "CS" interpretations to runtime environment.
 One is the process/OS level - some lump of hardware turned into a MINIX machine, an OS/400, QNX, z/OS, Multics one, defined in an applicable application binary interface (ABI).
At this level, memory usually gets allocated in segments or pages (taking care no information leaks). (In a conventional OS,) Requirements like amount and initialisation are taken from an "executable file" in an appropriate format.
It is a matter of definition whether "the compiler" is responsible for the generation of such a file from source code or just some intermediate code which may be executed by an interpreter, or statically analysed&improved, turned into assembly language, assembled into an object file/module, linked with other modules.

To me, the existence of a virtual machine is a philosophical question (as opposed to the existence of the computing hardware heating up my environment) - I take the pragmatic stance of accepting help, from a mere concept when that is what it is. Proponents of something like the Java virtual machine (JVM) (a popular target for compilers, btw.) are entitled to making the case for VM existence.

Regarding exactly when the compiler does something, anything going on during execution of the compiler should be beyond doubt. A compiler-centric view may include anything from decisions made during the specification of the compiler (like row-major or column-major layout of two-dimensional arrays) up to and during the execution of the compiled program - anything not due explicitly to a specific part of the source code, but the language specification implemented by the compiler.

 This is the programming language level - what gets your main() running (and possibly constructors&co. of statically allocated objects before that), that Begin…End;-block implicitly prefixed with Simula - you name it. It takes care of memory(/address) allocation (and possibly initialisation) for a subroutine call stack (per coroutine/thread), "statically allocated" program data (those objects named in the source program - on behalf of the program source code/the coder/the one who started the program), "automatically allocated" space (e.g., for "local" variables in potentially recursive subroutine calls), "dynamically allocated" space (e.g. objects for linked data structures. "dynamically": as need arises during program execution, a "program request" for (memory for) another object may lead to the language runtime environment requesting more memory from the OS - often, the RTE manages a memory pool for smallish requests and makes largish ones to the OS).
"The compiler" decides about memory layout for multi-dimensional arrays. It arranges access to machine code for the "runtime library" - with OS support more often than not.
In all, a Forth machine, a Java, Fortran, Beta one.

Note that

• the paragraph quoted does not say the compiler [executes] the code
• creates and manages needs interpretation/leaves room for it
• one resource managed by one authority doesn't preclude the same resource being managed by another one - expect conflicting responsibilities handled usefully.