CDA-4101 Lecture 1 Notes

• Assume machine 'M' (hardware) defining language 'L'
• 'L' has very simple statements: add, move, compare
• Define 'L+' to be less tedious than 'L'
• Execution requires getting L+ programs to run on 'M'
• Translation: converting 'L+' programs into 'L'
• Interpretation: write a program in 'L' that reads 'L+' programs

• Language 'L' is paired with machine 'M'
• What if 'M' was just drawings and not yet built?
• Suppose design flaw prevents building 'M' in hardware.
• Suppose developers already began developing programs in 'L'
• After fixing the problems, machine 'M-' is built.
• We can execute the programs in 'L' as long as a compiler or interpreter can be built for 'L-'

• Better to separate the machine specification from the hardware realization.
• Define these as "virtual machines" (VMs)
• Whether or not the machine is ever built doesn't matter to the programmers
• Just need a way to eventually run in on some machine
• Using intrepretation and/or translation, hardware realization can be different from VM specification.

• Decoupling programming from hardware design
• VM acts as a specification that hardware designers and software programmers agree to and work towards.
• Engineers can change machine implementation details without worrying about the impact on the programmers.
• Programmers can write code without having to worry about hardware design changes.
• This all falls apart if either side deviates from the agreed VM specification.

Decoupling implementation details from the programmers view is extremely important at all levels of hardware and software (e.g., C++ interfaces and class specifications).

• VM specification serves to separate two levels of design
• The language 'L+' was a way to present a simpler view to programmers than the language 'L' provided.
• 'L+' defines a virtual machine 'M+' that programmers in 'L+' could use.
• 'M+' did not have to be built, but the simplification and separation from the details of language 'L' (and its machine 'M') helps the programmers.
• Someone could then build upon 'L+' and define 'L++' whicih is simpler still.

• Translator from L++ to L
• Translator from L++ to L+ and translator from L+ to L
• Interpreter written in L that reads L++ programs
• Interpreter written in L that reads L+ programs and interpreter in L+ that reads L++ programs
• Translator from L+ in L and an interpreter in L+ that reads L++ programs
• Interpreter written in L that reads L+ programs and translator from L++ to L+

All of these are possible. Decision depends on many factors: e.g., the difficulty/complexity of designing each interpreter/compiler.

Someone can then define 'L+++' and so on.

In reality, the motivation and causes for where and when to define each level is fairly complicated and changes over time as software and hardware evolves.

• Internally, compiler writers often define their own VM, or representation for a computer program.
• Source code in the high-level language is converted to this representation.
• This internal representation is independent of a particular piece of hardware
• The last step will be a code-generation phase that will generate the appropriate machine-level/assembler code.
• Benefits:
  • Source code to VM and VM to assembly are both easier than trying to go from source to assembly.
  • the compiler can be used for many machines by only rewriting the code generation part.
  • code generation piece can be used for many languages with apprpriate front-end.
  • All the parsing and optimizations can be done on the VM spec, so these too become architecture independent.

• Defining levels reducing the complexity considerably.
• Even C++ could be implemented in hardware, but it would not be cost effective
• Early GNU C++ compiler would first generate C code and then the GNU C compiler would be called

We will define some standard levels of modern computers broadly and subsequent lectures will concentrate on specific levels in depth.

• Language 'L0' is the machine language of the virtual machine 'M0'
• Virtual Machine 'M0' happens to be the real hardware that was built.
• All level/languages above this will define a hierarchy of VMs, all ultimately executing on the 'M0' hardware
• Level 1 and upwards must either be translated to, or interpreted on a lower-level

The book says:

A person whose job it is to write programs for level 'n' virtual machine need not be aware of the underlying interpreters and translators.

• In theory, and for the most part this is true.
• However, some knowledge of the lower levels is sometimes required and often helpful.
• Especially applies when considering performance issues and helping with debugging.
• How useful this is depends on how sophisticated a program you are working on.

If this was completely true, then this course would not be relevant to someone just interested in being a C++, Java or other.

• Level 0 is a digital logic circuit that effectively "interprets" L0 programs.
• The digital logic circuit itself is comprised of simpler digital components, thus defining another level of abstraction.
• We call this the "device level" and it consists of digital logic gates and circuits.
• We will look at this level in this course

Example: NAND gates

• Yet another level below device level.
• How digital gates work
• realm of electrical engineering, not this course
• This is analog, not digital

• Level 0 language L0 is the language of digital circuits
• Language L1 sees a collection of registers, an ALU and other lower level components.
• Add, bit shift, compare, move, etc.

Example: AMD K5

• typically the machine language of the computer.
• Level 1 is responsible for converting (interpreting) the L2 instructions into the primitives add, compare and move instructions.
• Level 0 will then interpret these primitive into the actual gate operations needed.

Level 1 can either be software or hardware.

When Level 1 is in software:

• it is called a ``microprogram''.
• allows flexibility to updating, bug-fixing, extensions without having to change the hardware design and manufacturing process.

When Level 1 is hardware:

• the division between level 0 and level 1 gets blurred.
• there is one piece of hardware whose design effectively interprets L2 instructions.
• difficult to pick out hardware pieces to define which level thewy are on.

Level 2 is pretty standard, this is the machine language and the only real variation below this is whether level 1 has a microprogram or not. However, above Level 2 there tends to be a lot more variation.

• the operating system presents a more convenient view of the hardware.
• Many ISA instructions of level 2 appear identically in level 3, so these require neither translation or interpretation: i.e., partial interpretation
• Additional instructions are interpreted by the operating system.

Example: OSes

• Wide variety of ways to implement Level 3.
• Entire course devoted to this topic.

Examples of OS Conveniences: Processes and Memory

• ISA level: there is a single processor which can execute a single sequence of instructions and a finite fixed amount of memory to use for data and instructions.
• The operating system makes it much easier to have multiple programs executing at the same time, and can make each program have a simple view of the memory.
• Thus, to write one program, you do not have to worry about what other programs might also want to run at the same time, or what they might be doing to the memory hardware.
• Essentially, it creates the idea of virtual processors and virtual memory for programmers to use.
• The extra instructions added at level 3 by the operating system helps support these, so the operating system interprets these from the virtual worlds into the actual level 2 ISA instructions.

An application programmer can think about the virtual specification defined by an operating system and concentrate on the more critical parts of solving their problem. They are free from worrying about the details of process and memory management.

It is the system programmers who have written an interpreter (i.e., the operating system) that handles the conversion from the Level 3 language to the level 2 ISA language.

• Above the operating system, level 3, is what application programmers typically concern themselves with. The bulk of programmers are application programmers.
• Levels 2 and 3 are almost always interpreted: either by a microprogram, the hardware or the operating system. Above level three, translation becomes more common.

• there is often a one-to-one correspondance to many of the ISA instructions at Level 2 (and 3).
• some assembly languages can take advantage of OS features, so they are above OSes in the hierarchy
• some assmebly languages are mere symbolic versions of the machine language and thus con be transalated into L2 entirely.
• Assembly language allows you to use symbolic names and provides other conveniences (OS calls, simple math, etc.), so it is not the true machine language.
• The assembler is the translation from assembly language to machine language which mostly just needs to resolve all the symbolic names and substitute the right values.

• These lanaguages are problem-oriented: C, C++, Basic, Perl, etc.
• The language is defined in a way that makes solving certain classes of problems easy.
• A compiler can take these level 5 programs and convert them into level 3 or 4 programs.
• Converting Level 5 into Level 4 requires invoking an assembler (usually is done automatically behind the scenes.)

Java: Level 5 or 6?

Book claims Java at Level 5, but is it?

• The Java Virtual machine interprets JVM instructions into level 4 instructions, so JVM instructions are Level 5.
• However, there is a compilation step to take a Java program into JVM instructions,
• Seems like Java programs are at level 6.

• No universally accepted defintion of each.
• For us, computer organization will be looking at the computer from the component interaction level: e.g., buses, bus controllers, processors, hard-drives, video cards, keyboards, etc.
• Computer architetcure will be the programmers view: e.g., looking at how the processor converts ISA instructions into the digital logic functions needed to carry them out.

• For any software you create, someone could create a digital logic circuit to do the same thing.
• For any digital logic circuit you make, someone could write a program to do the same thing.
• Many things have migrated back and forth between the two as computers and operating systems have developed.
• Operating system development has driven a lot of hardware features:, interrupts, protected mode, page faults, etc.
• Emulators for all sorts of hardware are readily available from digital logic gate simulators, to old gaming console emulators, to emulating an entire PC.
• Microprograms are another great example of migration between software and hardware (read the text (section 1.1.3) for details).
• Also read about how operating systems evolved in text (Section 1.1.3)

• History is important; not specific times and dates, but general concepts and perspectives
• Read text (section 1.2)

• Book uses three as examples throughout, so read Section 1.4 from the text to get details:
  • Pentium II
  • UltraSparc II
  • picoJava II

• Chap. 2 - Computer Organization
• Chap. 3 - Digital Logic Level (Level 0)
• Chap. 4 - Microarchitecture Level (Level 1)
• Chap. 5 - Instruction Set Level (Level 2)