In order to do that we need some services the language interpreter provides to aid running the program. These services are called the language runtime or simply runtime.
What are these services?
It could mean several things. For example, if your language has a stack virtual machine it could mean the way the parameters are put onto the stack before function calls.
If the language has automatic memory management it needs a garbage collector and it will be provided by the runtime. Memory allocation/deallocation routines in case your language has manual memory management model. The runtime also provides disk I/O services. Parallel execution service if your language supports it, interaction with the runtime environment (reading environment variables), direct hardware access (reading from a DVD drive for example), reading from a keyboard, printing text to a screen, network I/O, and a lots of other things as well.
In several occasion, these services are provided by the operating system. In these cases the runtime is implemented as an abstraction layer – a wrapper around the OS machinery – to hide its complexity and to provide an API that is easy to use. So basically it provides a facade.
In languages compiled to direct machine code the runtime is compiled into the executable. This means every executable program has a copy of the whole runtime embedded into it. In interpreted languages the runtime is part of the interpreter, and for VM languages the runtime is part of the VM.
Now we really have everything in place to start thinking about the language we’d like to build.
Next time I will talk about the ASPL language, a toy language of my design I chose to implement for this blog.
Stay tuned. I’ll be back.