Linkage mechanisms and Z++
An interpreted language is signified by the fact that the source file is also the executable. The virtual machine for the language parses and executes the program. On the other hand, the source of a compiled language is mapped to an executable prior to actually executing the program. The mapping consists of a range of operations collectively referred to as compilation. In this note I would like to overview the linking phase.
The linking phase uses a variety of mechanisms. The old, and still very useful mechanism is called static linking, which requires support for building static libraries. It is not clear at all what static linking means in the context of languages like Java, while languages that support static linking can also do other forms of linking. The absence of static linking implies lack of assembly phase. We therefore classify Java and C# as partially compiled.
Another form of linking is resolving symbols at load time. For instance GNU C++ compiler supports this technique. A DLL, on the other hand, is loaded at run time with the possibility of loading different versions of a particular library. The latter capability is actually a nuisance and should be avoided. In particular if our code breaks with a newer version of a DLL, there is something really wrong with our code. After all our code is not supposed to depend upon internals of a library.
Java and C# use a variation of DLL. However, since they are platform-free the notion is referred to as remote linking. Note that in these languages remote linking means downloading classes to the site of the executing program. In other words, the library cannot execute on the remote node where it resides. This notion of linkage is useful in the context of namespaces. A program grabs the classes that it needs from the Internet in the course of its execution.
Another old mechanism for linking is Remote Procedure Call (RPC). As the name indicates, the execution of library functions takes place on remote nodes. In principle an RPC library is also a DLL because the actual linkage occurs at run-time.
Now, let us see how Z++ simplifies the picture through generalization. First, Z++ supports static linking exactly the same way as its subset C++. However, even static libraries are platform independent in Z++. Furthermore, assembly to the instruction set of the Z47 processor is the final phase of compilation as it is ordinarily understood.
A Z++ program is not distinguishable from a component or a dynamic library. Simply put, one Z++ program can load another compiled Z++ program just like a DLL. For instance when both programs reside on a single machine the linkage mechanism is conceptually similar to DLL. When the programs reside on two different machines, one of them can download the other as is done in remote linking (Java). Otherwise, the calling program can have the remote node load and execute the other program. In this case the calls to the remote module are equivalent to RPC.
The conclusion is that, static libraries are generalized to platform-independent libraries, and a program is generalized to a platform-free component. All signals and un-handled exceptions in the invoked module reach the calling module. This holds true regardless of whether the invoked module is running on the local or a remote node. The calling module can control the invoked module via invariants and constraints (contracts).
For illustrative code examples, please visit ZH Micro.
The linking phase uses a variety of mechanisms. The old, and still very useful mechanism is called static linking, which requires support for building static libraries. It is not clear at all what static linking means in the context of languages like Java, while languages that support static linking can also do other forms of linking. The absence of static linking implies lack of assembly phase. We therefore classify Java and C# as partially compiled.
Another form of linking is resolving symbols at load time. For instance GNU C++ compiler supports this technique. A DLL, on the other hand, is loaded at run time with the possibility of loading different versions of a particular library. The latter capability is actually a nuisance and should be avoided. In particular if our code breaks with a newer version of a DLL, there is something really wrong with our code. After all our code is not supposed to depend upon internals of a library.
Java and C# use a variation of DLL. However, since they are platform-free the notion is referred to as remote linking. Note that in these languages remote linking means downloading classes to the site of the executing program. In other words, the library cannot execute on the remote node where it resides. This notion of linkage is useful in the context of namespaces. A program grabs the classes that it needs from the Internet in the course of its execution.
Another old mechanism for linking is Remote Procedure Call (RPC). As the name indicates, the execution of library functions takes place on remote nodes. In principle an RPC library is also a DLL because the actual linkage occurs at run-time.
Now, let us see how Z++ simplifies the picture through generalization. First, Z++ supports static linking exactly the same way as its subset C++. However, even static libraries are platform independent in Z++. Furthermore, assembly to the instruction set of the Z47 processor is the final phase of compilation as it is ordinarily understood.
A Z++ program is not distinguishable from a component or a dynamic library. Simply put, one Z++ program can load another compiled Z++ program just like a DLL. For instance when both programs reside on a single machine the linkage mechanism is conceptually similar to DLL. When the programs reside on two different machines, one of them can download the other as is done in remote linking (Java). Otherwise, the calling program can have the remote node load and execute the other program. In this case the calls to the remote module are equivalent to RPC.
The conclusion is that, static libraries are generalized to platform-independent libraries, and a program is generalized to a platform-free component. All signals and un-handled exceptions in the invoked module reach the calling module. This holds true regardless of whether the invoked module is running on the local or a remote node. The calling module can control the invoked module via invariants and constraints (contracts).
For illustrative code examples, please visit ZH Micro.
Labels: dynamic link, remote link, static library, Z++, Z47
0 Comments:
Post a Comment
<< Back to Blogger Start Page >>