Introduction to Programming PT-104 | UNIT 1ASSIGNMENT | Research Popular Programming Languages | Associated with the Past Present and Future of Virtualization | | 9/30/2013 |

Introduction to Programming
23 September 2013

Unit 1 Assignment 1 Exploring Programming Languages
Platform virtualization vs. application virtualization
Virtual machines (VMs), in their first incarnation, were created by IBM 60 years ago as a way to share large and expensive mainframe systems. And although the concept is still applied in current IBM systems, the popular concept of a VM has broadened and been applied to a number of areas outside of virtualization.
Virtual machine origins
The first operating system to support full virtualization for VMs was the Conversational Monitor System (CMS). CMS supported both full virtualization and paravirtualization. In the early 1970s, IBM introduced the VM family of systems, which ran multiple single-user operating systems on top of their VM Control Program—an early type-1 hypervisor.
The area of virtualization that IBM popularized in the 1960s is known asplatform (or system) virtualization. In this form of virtualization, the underlying hardware platform is virtualized to share it with a number of different operating systems and users.
Another application of the VM is to provide the property of machine independence. This form, called application (or process) virtualization, creates an abstracted environment (for an application), making it independent of its physical environment.
Aspects of application virtual machines
In the application virtualization space, VMs are used to provide a hardware-independent environment for the execution of applications. For example, consider Figure 1. At the top is the high-level language, which developers use to construct applications. Through a compilation process, this high-level code is compiled into an intermediate representation called object code. In a non-virtualized environment, this object code (which is machine independent) is compiled into the native machine code for execution on the physical platform. But in an application virtualization environment, the object code is interpreted within an abstract machine to provide the execution. The key advantage here is that the same object code can be executed on any hardware platform that supports the abstract machine (the interpreter).
Figure 1. Application VM for platform independence

In addition to creating a portable environment in which to execute the object code, application virtualization provides an environment in which to isolate the VM from other applications running on the host. This setup has a number of advantages, such as detailed resource management and security.
The object code for a VM is also called bytecode, specifically defining an instruction set that an interpreter executes. The term bytecode evolved from implementations that efficiently implemented their virtual instruction sets as single bytes for simplicity and performance.
Now, let's look at some of the historical uses for application virtualization and explore some of its modern uses.

BCPL, then and now
Although BCPL originated in 1966, it's still under active development today by its creator, Martin Richards. BCPL's first compiler was written for the IBM 7094 system under the Compatible Time Sharing System, one of the first time-sharing operating systems developed. Today, you can use BCPL on a variety of systems, including Linux.
Virtual machines today
The use of VMs to provide an abstraction to the physical host is historically a common method and today evolves and finds application. Let's look at some of the newer open source solutions that push the concept of VMs into the future.
Dalvik VM
Dalvik is an open source VM technology developed by Google for the Android operating system. Android is a modified Linux kernel that incorporates a software stack for mobile devices (see Figure 2). Unlike many VM technologies that rely on stack-based architectures, the Dalvik VM is a register-based virtual architecture (see Resources for more information on the architecture and instruction set). Although stack-based architectures are conceptually simple and efficient, they can introduce new inefficiencies, such as larger program sizes (because of stack maintenance).
Figure 2. Simple architecture of a Dalvik software stack

Because Dalvik is the VM architecture, it relies on a high-level language compiled into the bytecodes that the VM understands. Rather than reinvent the wheel, Dalvik relies on the Java language as the high-level language for application development. Dalvik also relies on a special tool called dx to convert Java class files into Dalvik VM executables. For performance, the VM may further modify a Dalvik executable (dex) for further optimizations, including JIT compilation, which translates the dex instructions into native instructions for native performance. This process is also known as dynamic translation and is a popular technique for increasing the performance of VM technologies.
As shown in Figure 2, a Dalvik executable (along with an instance of the VM) is isolated as a single process in Linux user space. The Dalvik VM has been designed to support execution of multiple VMs (in independent processes) simultaneously.
The Dalvik VM is not implemented on the standard Java runtime and therefore does not inherit the licenses over it. Instead, Dalvik is a clean-room implementation published under the Apache 2.0 license.
Parrot
Another interesting open source VM project is Parrot. Parrot is another register-based VM technology that was designed to efficiently execute dynamic languages (languages that perform certain operations at run time that are commonly performed at compile time, such as altering the type system).
Parrot was originally designed as a run time for Perl6, but it is a flexible environment for execution of bytecodes for many languages (see Figure 3). Parrot supports several input forms, including the Parrot Abstract Syntax Tree (PAST), which is useful for compiler writers; the Parrot Intermediate Representation (PIR), which is a high-level representation that can be written by people or automatically by compilers; and the Parrot Assembly (PASM), which is below the intermediate representation but useful both for people and for compilers. Each form is translated and executed in Parrot bytecode on the Parrot VM.
Figure 3. Simple architecture of the Parrot VM

Parrot supports a large number of languages, but one aspect that makes it so interesting is its support for both static and dynamic languages, including specific support for functional languages. Listing 1 shows a simple use of PASM. To install Parrot with Ubuntu, simply use apt-get: sudo apt-get install parrot
Even with the high-level abstraction that PASM provides, PIR is even more comfortable to high-level programmers. Listing 2 provides an example program written in PIR and executed by the Parrot VM. This example declares a subroutine called square that squares the number and returns it. This process is called by the main subroutine (labeled with :main to tell Parrot to run it first) to print the result.
Parrot provides a rich application virtualization environment for the development of machine-independent applications that also seek high efficiency. You can find a large number of languages that support compiler front ends designed for Parrot, including C, Lua, Python, Scheme, Smalltalk, and many others.
The Future
So far, you've seen the historical uses of application virtualization, including two recent examples. Dalvik is powering application development within current handsets, and Parrot provides an efficient framework for compiler writers for static and dynamic languages. But the concept of application virtualization is being implemented in a number of other areas outside of the approaches explored thus far.
One particularly interesting use is likely running on the computer you're using right now. Systems that use the new Extensible Firmware Interface (EFI), which is a BIOS replacement, can implement firmware drivers in what's called the EFI Byte Code (EBC). The systems firmware includes an interpreter that is invoked when an EBC image is loaded. This concept was also implemented in Open Firmware by Sun Microsystems using Forth (a language that includes its own VM).
In the game world, the use of application virtualization is not new. Many modern games include scripting of nonplayer-character behaviors and other game aspects using languages that execute bytecodes (such as Lua). But the concept of application virtualization in games actually goes back much farther.
Infocom, the company that introduced text-based adventures such as Zork, saw the value in machine independence in 1979. Infocom created a VM called the Z-machine (named after Zork). The Z-machine was a VM that permitted an adventure game to be more easily ported to other architectures. Rather than having to port the entire adventure to a new system, an interpreter would be ported that represented the Z-machine. This functionality simplified the porting process to other systems that may have different language support and entirely different machine architectures. Although Infocom's goal was to ease the pain in porting between the architectures of their day, their work continues to simplify porting and results in making these games accessible to a new generation (even on mobile platforms).
Other game applications of VMs include the ScummVM (which provides a VM environment for the Script Creation Utility for Maniac Mansion (SCUMM) scripting language (created in 1987). SCUMM was developed by LucasArts to simplify development of a graphical adventure game. ScummVM is now used to play a large number of text and graphical adventure games on a variety of platforms.
Summary
There are several uses of the term “virtual machine”. In general they seem to describe a program that behaves somehow as a machine. The “Java Virtual Machine” is such a usage. I want to tell here about a narrower earlier kind of virtual machine that was once better known among programmers. (As of 2006 the original idea has become better known again.)
When IBM introduced the 360 model 67, circa 1967, it was IBM’s first major system with virtual memory. When the machine was announced a software system called TSS was promised. Perhaps this was a reaction to the earlier Multics announcement. TSS was a substantial departure from IBM’s other systems and was slow to be delivered. A team of IBM people in Cambridge MA conceived and built a program for the 67 that would provide the illusion of several standard 360’s which lacked virtual memory. This program was called CP 67. The Cambridge team also produced a simple interactive one user operating system called CMS. CMS would run happily and efficiently on one of the virtual machines provided by CP 67, or on a real 360 for that matter. Tom Van Vleck provides very interesting history and references. In fact he provides much of the information that I had intended to write here. I will repeat little of his information here.
As of several years ago, VM/370, a direct descendant of CP 67, was used about equally by users of CMS and those who needed to run various alternate operating systems for reasons such as testing.
Today a rather direct descendant of CMS runs on VM/390. IBM has had a policy for about two decades now of phasing out VM. It is yet heavily used inside and outside of IBM. Ironically the developers of competing operating system within IBM use CP/390 very heavily to test and debug their systems. IBM now (1999) recommends VM/390 for Y2K testing. Here is an interesting brochure describing IBM’s 2006 virtual offering which claims VM/370 heritage.
VMware provides a similar system for Intel 32 bit machines. Many of the points of their FAQ make sense in light of virtual machine strategies. OpenVX is an open source project. Xen from Cambridge University is a similar open source system. Intel’s Vanderpool technology should make their new hardware more adept at virtual machines.
I hope the reader can see what I tried to do here, I brought the course subject of programming and integrated with an area that I am personally interests me and the will define the future and development of more complex but and usable code and we just might get that machine to say maybe. 1