An unconventional proposal: using the x86 architecture as the ubiquitous virtual standard architecture

Abstract

There are 100+ million computers in the world. Even smaller organizations have easily 100+ machines; 10,000+ are typical for medium-sized organizations like a university or a bank. Current network technology is so ubiqitious and so powerful that we increasingly use these crowds of computers as one “technical being” instead of thinking of them as single machines. Consequently, we try to support distributed applications, not only by moving data around but also by remote execution of downloaded/uploaded code (applets, servlets) and even dynamically migrating active objects, i.e., curently executing programs (agents, load distribution). Unfortunately, not all of these 100+ million machines are compatible with each other. Currently, in the workstation/PC/NC segment, we see about 7 different hardware architectures: x86, PowerPC, Alpha, Mips, Sparc, PA-Risc, 68K. Some architectures are likely to disappear over time, e.g. 68K; however, new ones will show up (perhaps Intel’s IA-64). Heterogeneity will probably remain a problem over the next decade. More or less compatible OS APIs and tools, in particular compilers, help to move a source program from an x-machine to a y-machine. Moving a compiled program is harder; moving a currently executing program (migrating) between x and y is the hardest. One approach to move compiled programs between architectures is based on architectureindependent intermediate representations for compiled programs, e.g. Java bytecodes [10] or slim binaries [6]. However, it does not seem likely that in the near future all compilers will use a single intermediate language. (The language community has dreamed about the UNCOL (unitary compiler language) approach for nearly 40 years [15]. The UNCOL idea is to have a single language-independent code generation interface and thus architectureindependent compilers.) So the mentioned approach is restricted to certain programming languages and does not (yet?) give us general mobility for compiled programs. To solve the inter-architecture mobility problem for portable agents and for load distribution, we must be able to migrate a currently executing program with all its data, including temporary stack and heap data. A first approach to this problem is the ubiquitous interpreter. For example, the Aglets system [9] uses a JVM; Ara [11] uses Tcl. A second approach [14] is based on generating special (native) code that permits migration at certain synchronization points (“bus stops”) (Per architecture, a native-code version was generated when the source was compiled.). Similar to the techniques mentioned in the previous paragraph, both solutions suffer from the fact that they are specific to a single language.