Using the DirectX SDK in Windows 8 with Visual C++ 2010

This post is a result of some insight and necessary steps to get the June 2010 DirectX SDK working on a Windows 8 system, with Visual C++ 2010 express. Given the fact that DirectX 11 comes bundled in with the Windows 8 SDK, my stubbornness to change the configuration is due to the fact that I wanted to follow Frank D. Luna’s latest book, mirroring the same development environment (Visual Studio 2010 and the DirectX SDK) in my Windows 8 machine. Without further ado, lets dive in to the details…

  • Windows 8 comes with DirectX bundled in – The Windows 8 SDK comes with the DirectX SDK bundled in, and in turn, Visual Studio 2012 comes with the Windows 8 SDK. This means, you can download VS 2012, and start writing DirectX code without any further configuration. Microsoft recommends (Specifically in this blog), that developers transition to coding DirectX application using the new Windows 8 SDK and VS2012. If you are planning to go down this route, just install VS 2012 Express for Desktop on your Window 8 machine, and try out these great tutorials.
  • Windows 8 Contains DirectX 11.1 – What you will not be able to get from the DirectX SDK are the new features available in DirectX 11.1. This does not pose much of a problem, as much of the DirectX code out there is based on the DirectX SDK, and DirectX 11.1 features have not been widely adopted yet. If you are interested in the new DirectX 11.1 features, head over to this page and check them out. But bear in mind that you need to develop using the Windows 8 SDK if you are planning to use it (The windows 8 SDK is available as a separate download if you want to develop in Windows 7 for example).

If you are like me and want to use Visual C++ 2010 and the June 2010 DirectX SDK in Windows 8, then the below steps outline what needs to be done (I am assuming you are using a Windows 8 machine):

  • Install Visual C++ 2010 Express Edition – Navigate to the download page for VC++ 2010 express and install the product on your Windows 8 machine. (On Windows 8, after installation, there were some problems where the product did not fire up, stating that I needed to install the service pack for all VS2010 products in my system. When downloading and installing the service pack, some errors were thrown as well. But after restarting the machine and firing up VC++ 2010 Express, it worked properly… am still investigating why all this fuss. This seems to happen if you have other VS2010 express edition products installed already).
  • Install the DirectX SDK on your machineGo to the DirectX SDK download page, download the SDK and install in your system. One thing to note when installing in Windows 8, you will get installation errors if there are existing 32-bit and 64-bit VC++ 2010 redistributables installed in your system (This is because the DirectX SDK uses an older version of them). Follow the steps outlined in this page, in order to get the DirectX SDK installed properly on your Windows 8 system.

If everything went well, you should be up and running in coding and building DirectX applications using VC++ 2010 (provided that you link the appropriate libraries and set the folder paths in the project settings) on your Windows 8 system.


Infragistics UltraWebGrid column format not being applied

Just a short post today, recalling an incident I came across recently, which I thought I should jot down here, and hopefully It’ll save someone else a headache.

If you have been working with the 3rd party UltraWebGrid control for offered by Infragistics, you would have worked with columns where you might have wanted to display numerical values formatted in a certain way (for example, you may want to show 12, 300, 450.0 instead of 12300450.0000). This is done by setting the format expression in the column.Format property inside the ‘InitializeLayout()’ UltraWebGrid method. This is exactly what I was doing but was puzzled to have rows of integers merged from two DataTable sources showing different formats, even though each Integer in the rows were applied the same column.Format expression in code. The first few integers would display in the correct format I apply, but sometimes the last few integers don’t have the formatting applied.

This was getting way too frustrating till I (out of curiosity, and nothing else to try) wrote the following line of code before the ‘column.Format’ expression:

string dType = column.DataType;

When I debugged the code, one set of integers from the original DataTable was of type ‘System.Decimal’, and displayed correctly, but the second set of merged integers from the second DataTable was of type ‘System.String’. When I set the following line of code inside the loop applying the formatting to the column.Format property, all the integers displayed in the correct format:

column.DataType = “System.Decimal”;

So bottom line? The UltraWebGrid control cannot format columns with decimal format expressions if even one value in the column is going to be of a type other than ‘System.Decimal’. If there are several columns which will display numerical data in a certain format that you need, it would be defensive coding to write the logic in UltraWebGrid_InitializeLayout() as follows:

foreach (<column in UltraWebGrid that is going to display numeric values>) {

column.DataType = “System.Decimal”;

column.Format = <your numeric format expression here>;


2012 in review

The stats helper monkeys prepared a 2012 annual report for this blog.

Here’s an excerpt:

600 people reached the top of Mt. Everest in 2012. This blog got about 5,600 views in 2012. If every person who reached the top of Mt. Everest viewed this blog, it would have taken 9 years to get that many views.

Click here to see the complete report.


In a 3D game environment, vectors are used to hold the values of points or vertices. Thus a vector would contain a coordinate [x, y, z] which represents the specific vertex in 3D space. Points are defined such by vectors because the start position of the vector is usually taken as [0, 0, 0] which is the origin of the coordinate space. Thus all the vertices in 3D models and game elements are represented by vectors, but it is important to remember that vectors are not 3D vertices. (There is another type of vector that is represented by 4 coordinates [x, y, z, w], which are homogenous coordinates. We will talk about this in a later post dedicated solely to this very important and interesting topic).

Another place where vectors are used are  surface normals. Every 3D surface has a surface normal, which is nothing but a vector pointing away from the surface and perpendicular to that surface. This vector (surface normal) determines how light sources in the environment light up the specific surface. This is just one aspect of the surface normal, as it is used in many other places in the game. Vectors are also used in shading (which we will talk about later), and dynamically processing visual elements in the game.

Simply put, vectors are one of the most used constructs in 3D games. This is why learning and understanding about vectors and their operations is very important. Without further ado, lets dive in to learn about vector operations and some basic linear algebra.


The zero vector is the additive identity in the set of vectors. The 3D zero vector would be denoted by [0, 0, 0]. This vector is a special vector because it is the only vector with no magnitude or direction. It would be easy to assume the zero vector as a point, but the reader should remember that a point represents a location. It is better to remember the zero vector as a vector with zero displacement.


Vectors negation can be related to multiplication of scalar numbers by -1. The negated vector is known as the additive inverse of the original vector. A vector of any dimension is negated by all its individual components as shown below:

– [x, y] = [-x, -y]

-[x, y, z] = [-x, -y, -z]

Geometrically speaking, vector negation produces a vector same as the original, but with opposite direction.


Vectors have a magnitude (length) which can be calculated simply by taking the root of the sum of squares of the individual dimensions. This is very simple if you remember the very basic skill of calculating the length of the hypotenuse in a right angled triangle using the Pythagorean theorem (for 2 dimensions).

For a 2D and 3D vector, the magnitudes are defined as below, respectively:



Vectors can be multiplied by scalars, and this happens by multiplying the individual components of the vector by the scalar value. What we geometrically obtain by scalar multiplication is another vector that is parallel to the original vector, but which could differ by magnitude or direction, depending on the scalar value. Some examples are given below:

k[x, y, z] = [kx, ky, kz], -2[4, 0, 1] = [-8, 0, -2]

Vectors can be divided by scalars as well, and this would be equivalent to multiplying the vector with the reciprocal of the scalar value, which is shown as follows:

1/k[x, y, z] = [x/k, y/k, z/k]

Some important aspects to note:

  • We do not use the multiplication sign in scalar-vector multiplication, nor the division sign.
  • Multiplication and division take precedence over addition and subtraction.
  • Vector negation is a special case of scalar multiplication, where the scalar value is always -1.
  • The geometric interpretation of scalar – vector multiplication is the scaling of the vector by a magnitude of |k|, the scalar value.


In many situations, it is not the magnitude of the vector that is important, but the direction. In these cases it is convenient to work with unit vectors, which have the same direction of the original vectors, but their magnitude is 1. The process of taking a vector, and converting it into a vector of magnitude 1 while maintaining the direction, is known as vector normalization. The unit vector is known as the normal.

A vector is normalized by dividing the vector by its magnitude (scalar division, as the magnitude value is a scalar). The result is a vector which is the normal to the given original vector:

Vnorm = V/||V||, Where V is not zero.

The below image (courtesy of the book 3D math primer for graphics and games development, by F.Dunn and I.Parberry) show unit vectors in 2D space, which touch the surface of a circle of unit radius. In 3D space, unit vectors would touch the surface of a sphere of unit radius:



Vectors can be added or subtracted only when their dimensions are equal. The individual components of the vectors are added or subtracted to obtain the resultant vector. Though vector addition is commutative, vector subtraction is not. Examples of vector addition and subtraction is given below:

[2, 5, -1] + [3, 1, 0] = [5, 6, -1]

[3, 0, -3] – [5, -2, 0] = [-2, 2, -3]

The geometrical concept of vector addition and subtraction is the basic triangle rule. Given the vector addition of two vectors A and B as A+B, we need to find the resultant vector which has the starting position of A, but the ending position of B. This can be applied to many vectors. Vector addition may seem a simple enough concept, but we will later see a similar mechanism to transform vectors from one coordinate space to another.

In the next post, we will continue the rest of the vector operations, and look at two very important operations: Vector dot product and the vector cross product.


Well what are vectors anyway? The topic of vectors crop up in geometry, physics, engineering disciplines, mechanics, etc. How they are used, as well as their definitions at times, vary from context to context. Below I have listed how vectors are defined in some contexts:

1. In geometry, Euclidian (or spatial) vectors are line segments that represent length and direction.
2. In physics, vectors are used to show magnitude (usually in some unit) and direction, representing aspects such as velocity, force etc.
3. In linear algebra, vectors are elements of vector spaces, but unlike the above attributes of vectors, may not always be made up of real numbers.

I liken vectors to cross-cutting concerns in regular software applications. One example of a cross cutting concern in software applications is logging. In any one of the layers in a layered software architecture, logging is an important function that is applied across the layers (or used as an aspect, in Aspect Oriented Programming lingo).

Vectors are a cross-cutting concern across geometry, linear algebra, mechanics, engineering, fluid dynamics, etc. Vectors are a necessary and critical element in each of these areas, but is pretty much the same thing when taken by itself, and can be treated as an aspect, if I may use the term again from AOP.

Lets backtrack for a moment: A geometrical point is something and nothing at the same time. It is purely a location in space, but has no width, height, length, or any type of dimensional size. Next, a line can be defined as the straight path between two points. But can this straight path have any thickness or size? Points and lines are abstract idealizations in geometry, we cannot create or draw them, but we can visualize them by giving them size, thickness etc, that will make sense to our eyes as points and lines. A vector is yet another abstraction, which represents the magnitude of something (denoted by the length of  a directional line segment), and the direction of the acting element to which the magnitude is applicable. A vector starts from a initial point, and ends at a terminal point, with the directed line segment connecting the two points representing the magnitude and direction.

What game programmers need to know is that vectors can be represented as lists of numbers (or arrays, to be more accurate). If the initial point of each vector is taken as the origin of a coordinate system, every vector can be represented by a list of numbers. In two dimension, vectors can exist only on a plane, and thus need a minimum of two numbers (or values) to be defined in a list. In 3D, vectors can exist in 3D space, and need a minimum of three numbers to be defined. But it can be more than three dimensions, and we will see about higher dimension vectors in a future post, which has further implications in 3D game programming.

One important consideration when talking about vectors, is the relationship they have to points. Points were explained to represent only position. Vectors do not have position, but have magnitude and directions (displacement). But points do not have precise or absolute locations, their locations are defined relative to some coordinate space. Now, what happens when you draw a line segment from the origin of this coordinate space to the point in question? What we get is the displacement of that point, from the origin. Thus, in a given coordinate system, if we have a vector starting from the origin and describing a displacement of [x, y], we end up in the location of the point represented by [x, y]. What we need to remember is that points and vectors are conceptually (think physics) different but mathematically (think geometry) equivalent.

To sum up, vectors are simply directional line segments that represent a certain direction, and a magnitude which is denoted by the length of the line. If the vector is initiated from the origin of a coordinate system, the vector is equivalent to a point in the coordinate space whose coordinates are the same as for the vectors terminal point (And vice-versa: The displacement of a point in a coordinate space from the origin, is given by the vector that begins from the origin and ends at the point).

In the next post, we will look at where vectors are used in 3D games development, and some of the basic vector operations that we need to know about.



This question is best answered with a story given in the book ‘3D Math Primer for graphics and games development’ by Fletcher Dunn and Ian Parberry. The story goes that there are two cities, ignorant of each other and having their own coordinate system to map the different areas within the city. In the first city, the inhabitants do not care or have any knowledge of the coordinate system used in the second city and vice versa. They each have their own coordinate system and live their blissful day to day lives. But one day, the state engineer is tasked with building a road between the two cities. This creates a dilemma: the coordinate systems used by the cities (maybe with the origins at the city centers) is not adequate for the engineer. He needs a larger frame of reference, encompassing the two cities within it. He needs a new coordinate space.

The 3D models we see rendered in games are generally created using  3D modeling packages. For example, if I use the open source software ‘Blender’ to draw a 3D model that I will use in my game, say for example a Spherical spaceship, then in my modeling package the origin of the model will be in the center of the sphere, denoting (0, 0, 0). But when I import this model to my game, I need this model placed in reference to ‘something’ that represents the whole virtual world of the game. This ‘something’ is the world coordinate space. With regards to multiple coordinate spaces and computer games, three coordinate spaces are vitally important and need to be understood clearly: Object space, World space, and Camera space.

Object space is what I was describing above when I mentioned that the origin of the model is at the center of the spherical spaceship. Object space refers to the coordinate frame that the object is embodied and described in. World space is the global coordinate space, where everything of interest to the game in a graphical sense will reside. Finally, camera space is your view into the game world: The origin in camera space represents the point where the camera is stationed (your screen viewport) and where the view frustum begins. Camera space is the frame of reference relative to this 3D origin. Note that camera space can be treated as a ‘special object space’ where the object in question is the camera through which you view the game, and all the game constructs are referenced relative to this camera object space.


Objects in the world space of a game are rarely rigid objects. One example of a rigid object would be a model of a barrel. But even this object weaves a complicated path through world space when tumbling down a flight of stairs (based on the physics that is coded). Now think of a model of a Robot with a large number of abilities. Let’s assume for the moment that the robot has pincers that open and close in the Y-Z plane of world space, and a circular saw that is spinning in the X-Z plane of world space, and the robot is traveling along the Z-axis in world space (assume the robot is traveling away from our field of view, towards the horizon). The programmer trying to implement this behavior of the robot in only world space context is going to have a very hard time! This is because, the movements of the robot in world space is complicated when we look at the movement collectively. Add to this that the robotic pincers can move around, and the circular saw can change orientation, and you have a very complicated movement pattern in world space that the programmer would find hard to implement. This is why we need nested coordinate spaces.

Think of nested coordinate spaces as parent – child coordinate space nodes in the structure of a graph or tree. In the example of the robot, the object space of the robot is the parent space. The object spaces of the pincers and the circular saw can be child spaces of the robots object space, and the pincer blade object space can be a child space of the pincers object space. In this manner, if a given object space and object is responsible for the movement of the connected child coordinate space nodes, implementing complicated movements in world space becomes very much less complicated to the programmer. This reduction in complexity is due to the nested coordinate spaces of the object and constituent parts of the object, and the responsibility of each node in controlling the individual movements of the child nodes, which collectively results in the complicated movement we observe in world space.


Hopefully the reader has a clear understanding of object space and world space by now. I like to think of object space and world space as two parallel universes, and traveling between these two universes is the idea of transformation between object and world space. What I would like to focus on here, is the space between these universes of object space and world space, or the intermediate transition stage between the two universes, which is known as ‘inertial space’. The idea of inertial space would be more clear by referring the image shown below

inertial space

Inertial space has the same origin as that of object space, but the primary axes are aligned to the world space primary axes. How does inertial space help in transforming an object from object space to world space? Inertial space makes it easy by providing a two step process:first we transform from object space to inertial space by simple rotation. In this operation, the X and Y axes of the object space above, coincide with the X and Y axes of the inertial space, and the robots alignment becomes upright. Second, we move the location of the inertial space origin to coincide with the origin of world space, and this operation is known as translation. In this two step process, which is easy to think about individually, we have transformed the object from object space to world space, via the intermediary inertial space.

In the next post, we will look at an important concept and construct vital to game programming: Vectors.


The 3D coordinate system is a natural extension of the 2D cartesian coordinate system we are all familiar with and have studied. The cartesian coordinate system has an interesting history, first documented by the French mathematician Rene Descartes in around 1637. Early work in this time period dealt with only one or two axis coordinate systems, although later findings indicated that the mathematician Pierre de Fermat worked with a three axis (3D) system which was not published. The work done by these great men laid the basis for the great discoveries by Newton and Leibniz later on: the invention of the Calculus. But enough reflections on history, and back to the matter at hand…

We will be covering the following aspects in this first blog post dealing with 3D mathematics:

  • The 3D coordinate space
  • Left handed and right handed orientation
  • The need for multiple coordinate spaces (in games)


The 3D coordinate system consists of three lines or axes (singular form: axis), which are mutually perpendicular to each other, and form the abstract representation of the three dimensions that we humans are able to see. If we had the ability to sense or see in more than 3 dimensions, we would not be limited to the 3 axis system, though this limitation is absent in areas such as linear algebra where you can describe systems with any number of dimensions in an abstract sense. In real life, we see only in three dimensions, and will be our basis behind creating real life-like game environments and models.

The three axes are referred to as the X, Y, and Z axes. Any and every point in 3D space (relative to the axes) can be described in reference to these three axes. The point where the three axis lines intersect is known as the origin. The origin is to the 3D space, what the number zero is to the number line. A coordinate in 3D space is described by the length units projected on the X, Y, and Z axes respectively to reach that position, starting from the origin. Thus the position of the origin can be described as (0, 0, 0) and the point shown in the coordinate system below has the coordinates (x, y, z).


Left handed and right handed orientation is nothing more than a categorization of how the 3D axes can be aligned. If you take your left hand and extend the thumb, index, and third finger at right angles to each other, and hold your hand so that the thumb (positive x-axis) is pointing to your right, the index (positive y-axis) is pointing up, and the third finger (positive z-axis) is pointing towards the direction you are facing, then you have a left handed 3D coordinate system. If we do the same with our right hand, where the thumb, index, and third finger are the positive x, y, and z axes respectively, we have a right handed coordinate system. Notice that if you rotate the right handed orientation to match the x and y axis directions of the left handed system, only the positive z-axis changes direction. We could say that the difference between the orientations is that in a left handed system, the positive z-axis points away from us towards where we are facing, whereas in a right handed orientation, the positive z-axis points towards us. The figure below represents this fact.

image courtesy of

In the next post, we will learn about multiple (3D) coordinate spaces and nested coordinate space, and also how basic coordinate transformations can take place. Please leave any feedback on content, clarity of writing,  on what you think should be changed, or errata in general, and I will do my best to work on it.


Many a time I’ve heard statements like “Games programming? 3D graphics? that requires an awful lot of maths right? and graduate level math at that…” ….and therein onwards the interest dies off due to the pre-mis-conceptions about the role that mathematics will play in games development.

For a programmer/developer/software engineer, learning the concepts of 3D mathematics needed for developing games is not an impossible task (the math we use in 3D game programming is referred to as ‘3D math’ but is actually a composite collection of topics from different mathematical disciplines as we shall see shortly). Of course, there will be some due inherent complexity, as there should be with good reason, but we tackle complexity everyday in software engineering: software architecture and patterns, databases and database design, mastering specific technologies that we use to build systems with, web site user experience, all bring about their own inherent complexities, but we master them and control them in order to reach our objectives. In that regard, what is so different about 3D mathematics that we cannot master the complexity, understand it, and apply it? That being said, this may be a good time as any to elaborate on what 3D mathematics is made up of.

The math used in the rendering of 3D games is based on a sub-set of topics derived from the mathematical branches of linear algebra, (solid) geometry, real analysis, and higher algebra. In addition, any artificial intelligence used in game logic and physics simulations, employs real world physics and mathematics as well. But we are currently concerned with the mathematics needed for drawing and rendering 3D graphics for games, and that is what we will focus on at the moment, though we will discus all aspects of game programming, including AI, in later topics.

To this end, I will be creating a thread of posts in this blog that deal with 3D math topics in a linearly progressive fashion, including code examples showing their applications where possible. This is in order to show and  prove to the reader, that learning 3D mathematics is not the daunting task it is labeled to be, and also to pave the way for the game programming concepts and topics discussed in this blog that rely on mathematics. It is one of the most rewarding experiences, that when you are developing 3D computer games, you actually understand the mathematical concepts and principles behind what you are doing. For at that point, no aspect of the game is out of your control, as you know and understand exactly what is happening under the hood.

Agile estimation, Algorithm analysis, and Relativity…

No, Im not referring to Einsteins theory of relativity (though I can draw some parallel if I really think about it). Something I was reading in an algorithms/data structures book recently hit a profound note in my thinking, though we all have learnt and overlooked it at times. The topic was on analysis of algorithms using Big(O) notation, and the words that hit home were “relative rates of growth”. We all have learnt this before and understand the simple matter of comparing algorithms based on their growth rates. But when we think of comparing the relative rates of some functions, we are not talking about comparing the functions themselves anymore. For instance, say that f(n) = N^N and g(n) = 1000N. It does not make sense to say that f(n) < g(n), which will be true for all N less than or equal to 1000, but false for all N greater than 1000. Therefore, it is the growth rate of f(n) that is compared relative to the growth rate of g(n). In this context, it makes sense to say O(f(n)) > O(g(n)).

This made me jump track and think of Agile estimating. We estimate a base story and then estimate the remaining stories in the backlog relative to the base story value. There is no specific unit defined, but we call them story points. There is no specific time unit associated with the relative growth rate of an algorithm, or the relative complexity of a user story, but we use them in order to make some pretty important decisions in our work. We compare one algorithms complexity relative to another, and estimate task complexity relative to a another ‘known sized’ task. This makes me wonder, what else do we knowingly or unknowingly measure in relative terms in our day to day work?

There is little doubt that measuring something in relative terms produces more accurate results than say, labeling a specific time unit or complexity unit to a mathematical function or user story. It helps us measure and calculate things to large degree of accuracy, and has quite a number of similarities with relativity in physics in my opinion. One such similarity is the concept of a frame of reference: in algorithm analysis, a frame of reference could be the computer platform that the algorithm is run on, in agile estimation the definition is a bit fuzzier but could be the team size for example. You could come up with certain relative values in one frame of reference, and a completely different set of values in another, whether its relative story points, growth rates, or velocity (in physics). It’s interesting to see where this kind of thinking can lead us, and even more profoundly interesting would be to see the hint of a large as-of-yet undiscovered unified software theory of relativity, lurking under the bits and bytes out there waiting to be stumbled upon and discovered.

Stack based vs Register based Virtual Machine Architecture, and the Dalvik VM

[Kostja Stern has been kind enough to translate this article in russian, which can be found here]
A virtual machine (VM) is a high level abstraction on top of the native operating system, that emulates a physical machine. Here, we are talking about process virtual machines and not system virtual machines. A virtual machine enables the same platform to run on multiple operating systems and hardware architectures. The Interpreters for Java and Python can be taken as examples, where the code is compiled into their VM specific bytecode. The same can be seen in the Microsoft .Net architecture, where code is compiled into intermediate language for the CLR (Common Language Runtime).

What should a virtual machine generally implement? It should emulate the operations carried out by a physical CPU and thus should ideally encompass the following concepts:

  • Compilation of source language into VM specific bytecode
  • Data structures to contains instructions and operands (the data the instructions process)
  • A call stack for function call operations
  • An ‘Instruction Pointer’ (IP) pointing to the next instruction to execute
  • A virtual ‘CPU’ – the instruction dispatcher that
    • Fetches the next instruction (addressed by the instruction pointer)
    • Decodes the operands
    • Executes the instruction

There are basically two main ways to implement a virtual machine: Stack based, and Register based. Examples of stack based VM’s are the Java Virtual Machine, the .Net CLR, and is the widely used method for implementing virtual machines. Examples of register based virtual machines are the Lua VM, and the Dalvik VM (which we will discuss shortly). The difference between the two approaches is in the mechanism used for storing and retrieving operands and their results.

Stack Based Virtual Machines

A stack based virtual machine implements the general features described as needed by a virtual machine in the points above, but the memory structure where the operands are stored is a stack data structure. Operations are carried out by popping data from the stack, processing them and pushing in back the results in LIFO (Last in First Out) fashion. In a stack based virtual machine, the operation of adding two numbers would usually be carried out in the following manner (where 20, 7, and ‘result’ are the operands):


  1. POP 20
  2. POP 7
  3. ADD 20, 7, result
  4. PUSH result

Because of the PUSH and POP operations, four lines of instructions is needed to carry out an addition operation. An advantage of the stack based model is that the operands are addressed implicitly by the stack pointer (SP in above image). This means that the Virtual machine does not need to know the operand addresses explicitly, as calling the stack pointer will give (Pop) the next operand. In stack based VM’s, all the arithmetic and logic operations are carried out via Pushing and Popping the operands and results in the stack.

Register Based Virtual Machines

In the register based implementation of a virtual machine, the data structure where the operands are stored is based on the registers of the CPU. There is no PUSH or POP operations here, but the instructions need to contain the addresses (the registers) of the operands. That is, the operands for the instructions are explicitly addressed in the instruction, unlike the stack based model where we had a stack pointer to point to the operand. For example, if an addition operation is to be carried out in a register based virtual machine, the instruction would more or less be as follows:


  1. ADD R1, R2, R3 ;        # Add contents of R1 and R2, store result in R3

As I mentioned earlier, there is no POP or PUSH operations, so the instruction for adding is just one line. But unlike the stack, we need to explicitly mention the addresses of the operands as R1, R2, and R3. The advantage here is that the overhead of pushing to and popping from a stack is non-existent, and instructions in a register based VM execute faster within the instruction dispatch loop.

Another advantage of the register based model is that it allows for some optimizations that cannot be done in the stack based approach. One such instance is when there are common sub expressions in the code, the register model can calculate it once and store the result in a register for future use when the sub expression comes up again, which reduces the cost of recalculating the expression.

The problem with a register based model is that the average register instruction is larger than an average stack instruction, as we need to specify the operand addresses explicitly. Whereas the instructions for a stack machine is short due to the stack pointer, the respective register machine instructions need to contain operand locations, and results in larger register code compared to stack code.

A great blog article I came across (At this link), contains an explanatory and simple C implementation of a register based virtual machine. If implementing virtual machines and interpreters is your main interest, the book by ANTLR creator Terrence Parr titled ‘Language Implementation Patterns: Create your own domain-specific and general programming languages’, might come in very handy.

The DALVIK virtual machine

The Dalvik virtual machine is implemented by Google for the Android OS, and functions as the Interpreter for Java code running on Android devices. It is a process virtual machine, whereby the the underlying Linux kernel of the Android OS spawns a new Dalvik VM instance for every process. Each process in Android has its own Dalvik VM instance. This reduces the chances of multi-application failure if one Dalvik VM crashes. Dalvik implements the register machine model, and unlike standard Java bytecode (which executes 8 bit stack instructions on the stack based JVM), uses a 16 bit instruction set.The registers are implemented in Dalvik as 4 bit fields.

If we want to dive a bit deep into the internals of how each process gets an instance of the Dalvik VM, we have to go back to the beginning… back to where the Linux kernel of the Android OS boots up:


When the system boots up, the boot loader loads the kernel into memory and initializes system parameters. Soon after this,

  • The kernel runs the Init program, which is the parent process for all processes in the system.
  • The Init program starts system daemons and the very important ‘Zygote’ service.
  • The Zygote process creates a Dalvik instance which will be the parent Dalvik process for all Dalvik VM instances in the system.
  • The Zygote process also sets up a BSD read socket and listens for incoming requests.
  • When a new request for a Dalvik VM instance is received, the Zygote process forks the parent Dalvik VM process and sends the child process to the requesting application.

This is in essence, how the Dalvik virtual machine is created and used in the Android system.

Coming back to the topic of virtual machines, Dalvik differs from the Java virtual machine in that it executes Dalvik byte code, and not the traditional Java byte code. There is an intermediary step between the Java compiler and the Dalvik VM, that converts the Java byte code to Dalvik byte code, and this step is taken up by the DEX compiler. The difference between the JVM and Dalvik is depicted in the following diagram (Click here for image source):


The DEX compiler converts the java .class file into a .dex file, which is of less size and more optimized for the Dalvik VM.

In Ending…

There is no clear cut acceptance as to whether stack based virtual machines are better than register based implementations, or vice versa. This is still a subject of ongoing debate, and an interesting research area. There is an interesting research paper where the authors have re-implemented the traditional JVM as a register based VM, and recorded some significant performance gains. Hopefully, I have shown the reader the difference between stack and register based virtual machines, and also explained the Dalvik VM in some detail. Please feel free to provide your feedback or any questions you have regarding this article.