Welcome to the last unit of the first module in Nand to Tetris part two. When we designed this course, Norm and I decided that each module in the course will end with what we call a perspectives unit. This concluding unit has several purposes. First of all, we wish to use this unit in order to say a few words, about all sorts of things that we left out from the discussion. For example, if we decided not to deal with efficiency, we'd like to put it on the table explicitly. And we do this because we feel that it's important to not only celebrate what we did do in our projects and modules, but also to acknowledge what was left out and what is very important to include if we want to turn this, let's say, into a commercial product. And another purpose of the perspective units is to provide a historical context and to connect what we do in Nand to Tetris to also to a well-known hardware and software concepts that you may be familiar with. And if not, we'll introduce them to you during these units. And this will help you appreciate the fact that what we do in Nand to Tetris has not only a very exciting historical legacy but also far reaching practical implications. As you probably saw Nand to Tetris is a nitty-gritty course in which you have to work and develop stuff all the time and we want to use these units to take a break from the trenches, and be salt mines, to get out, breath some air, understand where we're coming from. Where we're going to, and connect what we do once again, to our environment. Now, these respective units are going to be question driven. That is we will read two or three questions that typically come up from learners when we teach these modules and we'll try to answer them. So let's see what is the first question. [COUGH] You mentioned that the VM is a rather old idea. How old is it? Well, as you may know, the personal computer era began in full swing in the late 1970s. And this happened when both Apple and IBM introduce to the market two personal computers that very quickly became widely popular. These early PCs came out with almost no software on them. During the same period there was a programming language called Pascal. Which was quite popular that it ran only on mainframe and what was known as mini computers. So people began to develop Pascal compilers for the new lines of IBM and Apple PCs. However, these machines use different processes, different chipsets and different operating systems. And therefore different Pascal compilers had to be developed. So if you were a software developer back then and you wanted your accounting software or your computer game that you developed to run on every PC out there, well, you had to use different compilers and you had to maintain and support multiple versions of your software. And clearly this led to numerous headaches and bugs and complaints and developer frustration. Also, IBM and Apple were rival companies and they had no interest whatsoever to help developers port their software to the other machine. Now, in order to deal with this cross platform challenge and frustration at the right level, which is the infrastructure level, several researchers and practitioners began to toy with and specify an early virtual machine architecture and language, which was called P-code. This P-code just like our own VM language, was based on a steck machine obstruction. So in order to realize this obstruction on both IBM and Apple computers, the P-code language was implemented on both lines of these machines. One implementations was designed to translate P-code programs into the Intel X86 instruction set which was used by the CPUs of IBM PCs. And another implementation frustrated the very same P-code programs into the Motorola 68,000 construction set, which was the CPU which was used by Echo computers back then. So you see that the whole concept was very similar to our own VM language and VM translator. The basic idea is to create a cool processing obstruction, a virtual machine. And then, to realize it on as many hydro platforms as we want. In our course, we do it on the HEC platform. So following these P-code implementations back in the 1970s, actually it was already in the beginning of the 1980s, other people went on to develop the skull compilers that generated P-code instead of machine language. And so, for the first time, the same skull program whether it was a computer game or whatever, the same program could run as it is on both IBM and Apple machines. Each using its own platform specific P-code implementation. Of course, this whole scheme was based on the assumption that the customers computer would be equipped with a suitable client based P-code implementation. And indeed during this time these P-code implementations were widely distributed in freely over the Internet so many people downloaded them and installed them in their computers. So the whole scheme work very nicely. So historically this was perhaps the first time that the notion of high level language begin to realize its full potential in a world consisting of different kinds of platforms and different machine languages. And you can see how the notion of an abstract virtual machine played such a central and sort of over arching role in this cross platform vision. In particular the VM language, or the VM architecture, provides an intermediate architecture or intermediate layer that hides not all but most of the gory details of the target hardware from the high level language. And this will become critically important when we'll set out to develop a compiler in this course later on in some of the future modules. So this was a long answer on the first question. And the second question is, how close is our VM to Java's JVM? So let's see. Java's virtual machine is also based on an intermediate language which in the Java case is called bytecode. And obviously there are quite a few technical differences between our VM language and this bytecode. For example, our language recognizes only 1 day to type a 16 bit integer and yet Java's bytecode commands are designed to manipulate integers, floating point, double precision, and also some other additional data types. So in that respect, it's much richer than our own VM language. Also, Java's bytecode offers also some high level obstructions that our VM language lacks like multiplication and division as well as low level commands like bit wise operations and so on. So it has more expressive power. And yet in it's most essential elements these two languages are quite similar. Both languages are stack based, both use their push and pop and both access their memory using virtual memory segments instead of symbolic variables. Now, it may be interesting to track the historical motivation for founding the Java language. Only two tier complication model. One that uses a virtual machine as an intermediate layer. Well, you see Java was developed in the mid 1990s by people who worked in a mighty company called San Micro Systems. And I kind of chuckle when I mention Sun because when I was at your average age, Sun was a revered company. And now, it's no more. Well, actually, it is buried somewhere in the bowels of Oracle. Who acquired Sun, very wisely I think, back in 2010. But going back to the mid 90s when the story of Java begins, the world of business and office applications was completely dominated by a company called Microsoft. And Sun, which was the archrival of Microsoft, wanted to distinguish itself by dominating everything else. And in order to achieve this dominance, Sun decided to create a new programming language in which one could write programs that will travel through the Internet and execute on any possible mobile device and digital appliance out there. Whether it is a PC, a digital television, a refrigerator, a washing machine, a sprinkler system, a toaster, whatever. Some wanted to connect everything and it wanted everything to be connected to some. And so they decided to base this vision on a universal VM architecture that could be implemented with relative ease on any given harder platform and digital device out there. Now, if the whole thing sounds to you quite similar to P-code, then you're absolutely right. It was the same problem, cross platform compatibility, and the same VM solution approach only on a much bigger, world class, megalomanic scale. So the basic idea, which still prevails is that a Java compiler first generates bytecode and this bytecode can be deployed through the Internet to any connected device and once it reaches it's destination there will be a client site JVN or a VM implementation that executes the code on the client device. How? By translating the VM code into the devices machine language just like we did with our own VM translator. Now, going back to the mid 90s, it turns out that historically, these lofty ideas of Sun were ahead of their time. And the beginning of Java was somewhat sluggish. But then, something completely unexpected happened. The cell phone happened. And before you could say iPhone, or Samsung, the world was flooded by numerous cellphone models using dozens of different processors, chipsets and operating systems. So all of a sudden the pre-sync Java Vision of running the same software on many different devices became extremely relevant. And it happened in a new setting, cell phones. Something that neither Sun, nor Microsoft, nor Intel could possibly imagine. So with the delay of about ten years, Java all of a sudden became the right thing in the right time. And so, there's no wonder that it also quickly became the language of choice for developing apps for mobile devices. And up until now, I think that Java is still the most popular programming language in the Android space. So all this goes to show, that if you come up with an elegant and clean idea, in our case, an abstract, hardware-independent virtual machine, then someone, at some point, will pick up this idea. Either you or someone else and turn it into an extremely useful and practical technology. Now, nothing can stop a good idea, it has a life of its own. Now, I would like to conclude this module with a note about efficiency. Throughout this module our contract called for developing a VM Translator, without requiring that the generated machine code will be either compact or efficient. Obviously, this is a very serious oversight. Because you see, you have to realize that a Vm Translator is a mission-critical program. It's a program that, in one way or another, lies in the very core of most PCs, tablets, and cell phones out there. And it may be called the JVM or KVM or ART or CLR, at the end of the day it's a VM Translator. And therefore, if your VM Translator generates inefficient and lengthy code, then all the apps that run on top of it will become sluggish and users will get frustrated. So in reality, developers of VM Translator work very hard to generate low level code which is a tight and efficient as possible. And that's something that, up until now, in non-tertiary spot, too, we've completely ignored. Also, I would like to point out that the stake architecture that we use so carefully in this course, is not really a necessary ingredient of a virtual machine. For example, the JVM which is installed these days on Android devices, uses another abstract architecture which is called register machine. This register machine is perhaps less elegant than the beautiful than our own stack architecture, but arguably, it generates code which is better optimized for processors of mobile devices. You see, when it comes to efficiency, developers of mission critical software layers are very opportunistic and they use anything that works better and faster. So we can go on and on with these questions and discussions and there's no one around here to tell me to shut up. So I'm going to force myself to stop and we'll meet again in the next module in which we'll continue to develop our VM obstruction and implementation and this will be module two.
