Operating Systems:
From 0 to 1

Preface

• You will learn how a computer works at the hardware level, and you will learn to write software to manage that hardware directly.
• You will learn the fundamentals of operating systems, allowing you to adapt to any operating system, not just Linux
• To hack on Linux internals suitably, you'll need to write at least one operating system on your own. This is just like applications programming: to write a large application, you'll need to start with simple ones.
• You will open pathways to various low-level programming domains such as reverse engineering, exploits, building virtual machines, game console emulation and more. Assembly language will become one of your most indispensable tools for low-level analysis. (But that does not mean you have to write your operating system in Assembly!)
• Writing an operating system is fun!

Why another book on Operating Systems?

Prerequisites

• Basic knowledge of circuits
  
  • Basic Concepts of Electricity: atoms, electrons, proton, neutron, current flow.
  • Ohm's law
  If you are unfamiliar with these concepts, you can quickly learn them here: http://www.allaboutcircuits.com/textbook/, by reading chapter 1 and chapter 2.
• C programming. In particular:
  
  • Variable and function declarations/definitions
  • While and for loops
  • Pointers and function pointers
  • Fundamental algorithms and data structures in C
• Linux basics:
  
  • Know how to navigate directory with the command line
  • Know how to invoke a command with options
  • Know how to pipe output to another program
• Touch typing. Since we are going to use Linux, touch typing helps. I know typing speed does not relate to problem-solving, but at least your typing speed should be fast enough not to let it get in the way and degrade the learning experience.

What you will learn in this book

• How to write an operating system from scratch by reading hardware datasheets. In the real world, you will not be able to consult Google for a quick answer.
• Write code independently. It's pointless to copy and paste code. Real learning happens when you solve problems on your own. Some examples are provided to help kick start your work, but most problems are yours to conquer. However, the solutions are available online for you after giving a good try.
• A big picture of how each layer of a computer related to each other, from hardware to software.
• How to use Linux as a development environment and common tools for low-level programming.
• How a program is structured so that an operating system can run.
• How to debug a program running directly on hardware with gdb and QEMU.
• Linking and loading on bare metal x86_64, with pure C. No standard library. No runtime overhead.

What this book is not about

• Electrical Engineering: The book discusses some concepts from electronics and electrical engineering only to the extent of how software operates on bare metal.
• How to use Linux or any OS types of books: Though Linux is used as a development environment and as a medium to demonstrate high-level operating system concepts, it is not the focus of this book.
• Linux Kernel development: There are already many high-quality books out there on this subject.
• Operating system books focused on algorithms: This book focuses more on actual hardware platform - Intel x86_64 - and how to write an OS that utilizes of OS support from the hardware platform.

The organization of the book

Part 1

provides a foundation for learning operating system.

• Chapter 1 briefly explains the importance of domain documents. Documents are crucial for the learning experience, so they deserve a chapter.
• Chapter 2 explains the layers of abstractions from hardware to software. The idea is to provide insight into how code runs physically.
• Chapter 3 provides the general architecture of a computer, then introduces a sample computer model that you will use to write an operating system.
• Chapter 4 introduces the x86 assembly language through the use of the Intel manuals, along with commonly used instructions. This chapter gives detailed examples of how high-level syntax corresponds to low-level assembly, enabling you to read generated assembly code comfortably. It is necessary to read assembly code when debugging an operating system.
• Chapter 5 dissects ELF in detail. Only by understanding how the structure of a program at the binary level, you can build one that runs on bare metal.
• Chapter 6 introduces gdb debugger with extensive examples for commonly used commands. After acquainting the reader with gdb, it then provides insight on how a debugger works. This knowledge is essential for building a debuggable program on the bare metal.

Part 2

presents how to write a bootloader to bootstrap a kernel. Hence the name “Groundwork”. After mastering this part, the reader can continue with the next part, which is a guide for writing an operating system. However, if the reader does not like the presentation, he or she can look elsewhere, such as OSDev Wiki: http://wiki.osdev.org/.

• Chapter 7 introduces what the bootloader is, how to write one in assembly, and how to load it on QEMU, a hardware emulator. This process involves typing repetitive and long commands, so GNU Make is applied to improve productivity by automating the repetitive parts and simplifying the interaction with the project. This chapter also demonstrates the use of GNU Make in context.
• Chapter 8 introduces linking by explaining the relocation process when combining object files. In addition to a bootloader and an operating system written in C, this is the last piece of the puzzle required for building debuggable programs on bare metal, including the bootloader written in Assembly and an operating system written in C.

Part 3

provides guidance on how to write an operating system, as you should implement an operating system on your own and be proud of your creation. The guidance consists of simpler and coherent explanations of necessary concepts, from hardware to software, to implement the features of an operating system. Without such guidance, you will waste time gathering information spread through various documents and the Internet. It then provides a plan on how to map the concepts to code.

Acknowledgments

Part I Preliminary

A

problem domain

problem domain is the part of the world where the computer is to produce effects, together with the means available to produce them, directly or indirectly. (Kovitz, 1999)

Figure 0.1: Problem domains: Software and Non-software.

One example of such scenario is the domain that is presented in this book: operating system. A certain amount of electrical engineering (EE) knowledge is required to implement an operating system. If a computer science (CS) curriculum does not include minimum EE courses, students in the curriculum have little chance to implement a working operating system. Even if they can implement one, either they need to invest a significant amount of time to study on their own, or they fill code in a predefined framework just to understand high-level algorithms. For that reason, EE students have an easier time to implement an OS, as they only need to study a few core CS courses. In fact, only “C programming” and “Algorithms and Data Structures” classes are usually enough to get them started writing code for device drivers, and later generalize it into an operating system.

Figure 0.2: Operating System domain.

One thing to note is that software is its own problem domain. A problem domain does not necessarily divide between software and itself. Compilers, 3D graphics, games, cryptography, artificial intelligence, etc., are parts of software engineering domains (actually it is more of a computer science domain than a software engineering domain). In general, a software-exclusive domain creates software to be used by other software. Operating System is also a domain, but is overlapped with other domains such as electrical engineering. To effectively implement an operating system, it is required to learn enough of the external domain. How much learning is enough for a software engineer? At the minimum, a software engineer should be knowledgeable enough to understand the documents prepared by hardware engineers for using (i.e. programming) their devices.

Learning a programming language, even C or Assembly, does not mean a software engineer can automatically be good at hardware programming or any related low-level programming domains. One can spend 10 years, 20 years or his entire life writing C/C++ code, and he still cannot write an operating system, simply because of the ignorance of relevant domain knowledge. Just like learning English does not mean a person automatically becomes good at reading Math books written in English. Much more than that is needed. Knowing one or two programming languages is not enough. If a programmer writes software for a living, he had better be specialized in one or two problem domains outside of software if he does not want his job taken by domain experts who learn programming in their spare time.

Documents for implementing a problem domain

Documents are essential for learning a problem domain (and actually, anything) since information can be passed down in a reliable way. It is evident that this written text has been used for thousands of years to pass knowledge from generation to generation. Documents are integral parts of non-trivial projects. Without the documents:

• New people will find it much harder to join a project.
• It is harder to maintain a project because people may forget important unresolved bugs or quirks in their system.
• It is challenging for customers to understand the product they are going to use. However, documents do not need to be written in book format. It can be anything from HTML format to database format to be displayed by a graphical user interface. Important information must be stored somewhere safe, readily accessible.

There are many types of documents. However, to facilitate the understanding of a problem domain, these two documents need to be written: software requirement document and software specification.

Software Requirement Document

What vs How

“what” and “how” are vague terms. What is the “what”? Is it nouns only? If so, what if a customer requires his software to perform specific steps of operations, such as purchasing procedure for a customer on a website. Does it include “verbs” now? However, isn't the “how” supposed to be step by step operations? Anything can be the “what” and anything can be the “how”.

Sketches

Software requirement document is all about the problem domain. It should not be a high-level description of an implementation. Some problems might seem straightforward to map directly from its domain description to the structure of an implementation. For example:

• Users are given a list of books in a drop-down menu to choose.
• Books are stored in a linked list”.
• etc

In the future, instead of a drop-down menu, all books are listed directly on a page in thumbnails. Books might be reimplemented as a graph, and each node is a book for finding related books, as a recommender is going to be added in the next version. The requirement document needs updating again to remove all the outdated implementation details, thus required additional efforts to maintain the requirement document, and when the effort for syncing with the implementation is too much, the developers give up documentation, and everyone starts ranting how useless documentation is.

More often than not there is no straightforward one-to-one mapping. For example, a regular computer user expects an OS to be something that runs some program with GUI, or their favorite computer games. But for such requirements, an operating system is implemented as multiple layers, each hiding the details from the upper layers. To implement an operating system, a large body of knowledge from multiple fields is required, especially if the operating system runs on non-PC devices.

It's best to include information related to the problem domain in the requirement document. A good way to test the quality of a requirement document is to provide it to a domain expert for proofreading, to ensure he can understand the material thoroughly. A requirement document is also useful as a help document later, or for writing one much easier.

• Intel® 64 and IA-32 Architectures Software Developer’s Manual (Volume 1, 2, 3)
• Intel® 3 Series Express Chipset Family Datasheet
• System V Application Binary Interface

MarginFigure 1: A lightbulb

MarginFigure 2: Modern transistor

A bit has two states: 0 and 1, which is the building block of all digital systems and software. Similar to a light bulb that can be turned on and off, bits are made out of this electrical stream from the power source: Bit 0 are represented with 0 v (no electron flow), and bit 1 is +3.5 v to +5 v (electron flow). Transistor implements a bit correctly, as it can regulate the electron flow based on voltage level.

MOSFET transistors

MarginFigure 3: Example: NAND gate

The theory behind logic gates

MarginFigure 4: 74HC00 chip physical view

---

Example 0.1. 74HC00 is a chip with four 2-input NAND gates. The chip comes with 8 input pins and 4 output pins, 1 pin for connecting to a voltage source and 1 pin for connecting to the ground. This device is the physical implementation of NAND gates that we can physically touch and use. But instead of just a single gate, the chip comes with 4 gates that can be combined. Each combination enables a different logic function, effective creating other logic gates. This feature is what make the chip popular.

Figure 0.3: 74HC00 logic diagrams (Source: 74HC00 datasheet, http://www.scrpdf.com/pdf/Semiconductors_new/Logic/74HCT/74HC_HCT00.pdf)

Sub-Figure a: Logic diagram of 74HC00

Sub-Figure b: Logic diagram of one NAND gate

Each of the gates above is just a simple NAND circuit with the electron flows, as demonstrated earlier. Yet, many these NAND-gates chips combined can build a simple computer. Software, at the physical level, is just electron flows.

How can the above gates be created with 74HC00? It is simple: as every gate has 2 input pins and 1 output pin, we can write the output of 1 NAND gate to an input of another NAND gate, thus chaining NAND gates together to produce the diagrams as above.

---

Beyond Logic Gates: Machine Language

Machine language

Example 0.2. A user can use 74HC00 chip without knowing its internal, but only the interface for using the device. First, we need to know its layout:

Figure 0.4: 74HC00 Pin Layout (Source: 74HC00 datasheet, http://www.nxp.com/documents/data_sheet/74HC_HCT00.pdf)

Then, the functionality of each pin:

Table 1: Pin Description (Source: 74HC00 datasheet, http://www.nxp.com/documents/data_sheet/74HC_HCT00.pdf)

Symbol	Pin	Description
1A to 4A	1, 4, 9, 12	data input
1B to 4B	2, 5, 10, 13	data input
1Y to 4Y	3, 6, 8, 11	data output
GND	7	ground (0 V)
Vcc	14	supply voltage

Finally, how to use the pins:

Table 2: Functional Description

Input		Output
nA	nB	nY
L	X	H
X	L	H
H	H	L

• n is a number, either 1, 2, 3, or 4
• H = HIGH voltage level; L = LOW voltage level; X = don’t care.

The functional description provides a truth table with all possible pin inputs and outputs, which also describes the usage of all pins in the device. A user needs not to know the implementation, but on such a table to use the device. We can say that the truth table above is the machine language of the device. Since the device is digital, its language is a collection of binary strings:

• The device has 8 input pins, and this means it accepts binary strings of 8 bits.
• The device has 4 output pins, and this means it produces binary strings of 4 bits from the 8-bit inputs.

The number of input strings is what the device understand, and the number of output strings is what the device can speak. Together, they make the language of the device. Even though this device is simple, yet the language it can accept contains quite many binary strings: $2^8+2^4=272$. However, the number is a tiny fraction of a complex device like a CPU, with hundreds of pins.

When leaving as is, 74HC00 is simply a NAND device with two 4-bit inputs

6

Or simply 4-bit NAND gate, as it can only accept 4 bits of input at the maximum.

.

	Input								Output
Pin	1A	1B	2A	2B	3A	3B	4A	4B	1Y	2Y	3Y	4Y
Value	1	1	0	0	1	1	0	0	0	1	0	1

The inputs and outputs as visually presented:

Figure 0.5: Pins when receiving digital signals that correspond to a binary string. Green signals are inputs; blue signals are outputs.

On the other hand, if OR gate is implemented, we can only build a 2-input OR gate from 74HC00, as it requires 3 NAND gates: 2 input NAND gates and 1 output NAND gate. Each input NAND gate represents only a 1-bit input of the OR gate. In the following figure, the pins of each input NAND gates are always set to the same values (either both inputs are A or both inputs are B) to represent a single bit input for the final OR gate:

MarginTable 1: Truth table of OR logic diagram.

A	B	C	D	Y
0	0	1	1	0
0	1	1	0	1
1	0	0	1	1
1	1	0	0	1

Figure 0.6: 4-bit OR chip made from four 74HC00 devices

Programming Languages

Assembly language is a step up from writing 0 and 1. As time goes by, people realized that many pieces of assembly code had repeating patterns of usages. It would be nice if instead of writing all the repeating blocks of code all over again in all places, we simply refer to such blocks of code with easier to use text forms. For example, a block of assembly code checks whether one variable is greater than another and if so, execute a block of code, else execute another block of code; in C, such block of assembly code is represented by an if statement that is close to human language.

Figure 0.7: Repeated assembly patterns are generalized into a new language.

• CMOS layer has a recurring pattern that makes sure logic gates are reliably translated to CMOS circuits: a k-input gate uses k PMOS and k NMOS transistors (Wakerly, 1999). Since digital devices use CMOS exclusively, a language arose to describe higher level ideas while hiding CMOS circuits: Logic Gates.
• Logic Gates hides the language of circuits and focuses on how to implement primitive Boolean functions and combine them to create new functions. All logic gates receive input and generate output as binary numbers. Thanks to this recurring patterns, logic gates are hidden away for the new language: Assembly, which is a set of predefined binary patterns that cause the underlying gates to perform an action.
• Soon, people realized that many recurring patterns arisen from within Assembly language. Repeated blocks of Assembly code appear in Assembly source files that express the same or similar idea. There were many such ideas that can be reliably translated into Assembly code. Thus, the ideas were extracted for building into the high level programming languages that everyone programmer learns today.

A mathematician, like a painter or a poet, is a maker of patterns. If his patterns are more permanent than theirs, it is because they are made with ideas.

Figure 0.8: Blade servers. Each blade server is a computer with a modular design optimize for the use of physical space and energy. The enclosure of blade servers is called a chassis.(Source: Wikimedia, author: Victorgrigas)

Figure 0.9: A typical desktop computer.

Mobile Computer

MarginFigure 5: An Intel 82815 Graphics and Memory Controller Hub embedded on a PC motherboard. (Source: Wikimedia, author: Qurren)

MarginFigure 6: A PIC microcontroller. (Soure: Microchip)

MarginFigure 7: Apple A5 SoC

Figure 0.10: FPGA Architecture (Source: National Instruments)

Computer organizations may vary depend on a manufacturer's design, but they are all originated from the Von Neumann architecture

8

John von Neumann was a mathematician and physicist who invented a computer architecture.

:

Figure 0.11: Von-Neumann Architecture

CPU

fetches instructions continuously from main memory and execute.

Memory

stores program code and data.

Bus

are electrical wires for sending raw bits between the above components.

I/O Devices

are devices that give input to a computer i.e. keyboard, mouse, sensor, etc, and takes the output from a computer i.e. monitor takes information sent from CPU to display it, LED turns on/off according to a pattern computed by CPU, etc.

• To use these devices, a programmer needs to controls the CPU to use the programming interfaces of other devices. CPU is the only way, as CPU is the only direct device a programmer can use and the only device that understand code written by a programmer.
• In a CPU, many OS concepts are already implemented directly in hardware, e.g. task switching, paging. A kernel programmer needs to know how to use the hardware features, to avoid duplicating such concept in software, thus wasting computer resources.
• CPU built-in OS features boost both OS performance and developer productivity because those features are actual hardware, the lowest possible level, and developers are free to implement such features.
• To effectively use the CPU, a programmer needs to understand the documentation provided from CPU manufacturer. For example, Intel® 64 and IA-32 Architectures Software Developer Manuals.
• After understanding one CPU architecture well, it is easier to learn other CPU architectures.

Registers

Registers

are a hardware component for high-speed data access and communication with other hardware devices. Registers allow software to control hardware directly by writing to registers of a device, or receive information from hardware device when reading from registers of a device.

Not all registers are used for communication with other devices. In a CPU, most registers are used as high-speed storage for temporary data. Other devices that a CPU can communicate always have a set of registers for interfacing with the CPU.

Port

Port

is a specialized register in a hardware device used for communication with other devices. When data are written to a port, it causes a hardware device to perform some operation according to values written to the port. The different between a port and a register is that port does not store data, but delegate data to some other circuit.

Figure 0.12: Motherboard organization.

• The first column is the address of an assembly instruction. In the above example, the address is 0x4004d6.
• The second column is assembly instruction in raw hex values. In the above example, the address is 0x55.
• The third column is the assembly instruction. Depends on the section, the assembly instruction might be meaningful or meaningless. For example, if the assembly instructions are in a .text section, then the assembly instructions are actual program code. On the other hand, if the assembly instructions are displayed in a .data section, then we can safely ignore the displayed instructions. The reason is that objdump doesn't know which hex values are code and which are data, so it blindly translates every hex values into assembly instructions. In the above example, the assembly instruction is push %rbp.
• The optional fourth column is a comment - appears when there is a reference to an address - to inform where the address originates. For example, the comment in blue:
  
      lea r12,[rip+0x2008ee] # 600e10 <__frame_dummy_init_array_entry>
  is to inform that the referenced address from [rip+0x2008ee] is 0x600e10, where the variable __frame_dummy_init_array_entry resides.

• Chapter 1 provides brief information about the manual, and the comment notations used in the book.
• Chapter 2 provides an in-depth explanation of the anatomy of an assembly instruction, which we will investigate in the next section.
• Chapter 3 - 5 provide the details of every instruction of the x86_64 architecture.
• Chapter 6 provides information about safer mode extensions. We won't need to use this chapter.

Instruction Prefixes

appears at the beginning of an instruction. Prefixes are optional. A programmer can choose to use a prefix or not because in practice, a so-called prefix is just another assembly instruction to be inserted before another assembly instruction that such prefix is applicable. Instructions with 2 or 3-bytes opcodes include the prefixes by default.

Opcode

is a unique number that identifies an instruction. Each opcode is given an mnemonic name that is human readable, e.g. one of the opcodes for instruction add is 04. When a CPU sees the number 04 in its instruction cache, it sees instruction add and execute accordingly. Opcode can be 1,2 or 3 bytes long and includes an additional 3-bit field in the ModR/M byte when needed.

Example 0.8. This instruction:

jmp [0x1234]

generates the machine code:

ff 26 34 12

The very first byte, 0xff is the opcode, which is unique to jmp instruction.

ModR/M

specifies operands of an instruction. Operand can either be a register, a memory location or an immediate value. This component of an instruction consists of 3 smaller parts:

• mod field, or modifier field, is combined with r/m field for a total of 5 bits of information to encode 32 possible values: 8 registers and 24 addressing modes.
• reg/opcode field encodes either a register operand, or extends the Opcode field with 3 more bits.
• r/m field encodes either a register operand or can be combined with mod field to encode an addressing mode.

The tables 3. and 3. list all possible 256 values of ModR/M byte and how each value maps to an addressing mode and a register, in 16-bit and 32-bit modes.

SIB

is Scale-Index-Base byte. This byte encodes ways to calculate the memory position into an element of an array. SIB is the name that is based on this formula for calculating an effective address:

$Effectiveaddress=scale*index+base$

• Index is an offset into an array.
• Scale is a factor of Index. Scale is one of the values 1, 2, 4 or 8; any other value is invalid. To scale with values other than 2, 4 or 8, the scale factor must be set to 1, and the offset must be calculated manually. For example, if we want to get the address of the n^th element in an array and each element is 12-bytes long. Because each element is 12-bytes long instead of 1, 2, 4 or 8, Scale is set to 1 and a compiler needs to calculate the offset:
  
  $Effectiveaddress=1*\left(12*n\right)+base$
  Why do we bother with SIB when we can manually calculate the offset? The answer is that in the above scenario, an additional mul instruction must be executed to get the offset, and the mul instruction consumes more than 1 byte, while the SIB only consumes 1 byte. More importantly, if the element is repeatedly accessed many times in a loop, e.g. millions of times, then an extra mul instruction can detriment the performance as the CPU must spend time executing millions of these additional mul instructions.
  The values 2, 4 and 8 are not random chosen. They map to 16-bit (or 2 bytes), 32-bit (or 4 bytes) and 64-bit (or 8 bytes) numbers that are often used for intensive numeric calculations.
• Base is the starting address.

Below is the table listing all 256 values of SIB byte, with the lookup rule similar to ModR/M tables:

r32(/r)			EAX	ECX	EDX	EBX	ESP	EBP	ESI	EDI
(In decimal) /digit (Opcode)			0	1	2	3	4	5	6	7
(In binary) REG =			000	001	010	011	100	101	110	111
Effective Address	SS	R/M	Values of SIB Byte (In Hexadecimal)
[EAX]	00	000	00	01	02	03	04	05	06	07
[ECX]		001	08	09	0A	0B	0C	0D	0E	0F
[EDX]		010	10	11	12	13	14	15	16	17
[EBX]		011	18	19	1A	1B	1C	1D	1E	1F
none		100	20	21	22	23	24	25	26	27
[EBP]		101	28	29	2A	2B	2C	2D	2E	2F
[ESI]		110	30	31	32	33	34	35	36	37
[EDI]		111	38	39	3A	3B	3C	3D	3E	3F
[EAX*2]	01	000	40	41	42	43	44	45	46	47
[ECX*2]		001	48	49	4A	4B	4C	4D	4E	4F
[EDX*2]		010	50	51	52	53	54	55	56	57
[EBX*2]		011	58	59	5A	5B	5C	5D	5E	5F
none		100	60	61	62	63	64	65	66	67
[EBP*2]		101	68	69	6A	6B	6C	6D	6E	6F
[ESI*2]		110	70	71	72	73	74	75	76	77
[EDI*2]		111	78	79	7A	7B	7C	7D	7E	7F
[EAX*4]	10	000	80	81	82	83	84	85	86	87
[ECX*4]		001	88	89	8A	8B	8C	8D	8E	8F
[EDX*4]		010	90	91	92	93	94	95	96	97
[EBX*4]		011	98	99	9A	9B	9C	9D	9E	9F
none		100	A0	A1	A2	A3	A4	A5	A6	A7
[EBP*4]		101	A8	A9	AA	AB	AC	AD	AE	AF
[ESI*4]		110	B0	B1	B2	B3	B4	B5	B6	B7
[EDI*4]		111	B8	B9	BA	BB	BC	BD	BE	BF
[EAX*8]	11	000	C0	C1	C2	C3	C4	C5	C6	C7
[ECX*8]		001	C8	C9	CA	CB	CC	CD	CE	CF
[EDX*8]		010	D0	D1	D2	D3	D4	D5	D6	D7
[EBX*8]		011	D8	D9	DA	DB	DC	DD	DE	DF
none		100	E0	E1	E2	E3	E4	E5	E6	E7
[EBP*8]		101	E8	E9	EA	EB	EC	ED	EE	EF
[ESI*8]		110	F0	F1	F2	F3	F4	F5	F6	F7
[EDI*8]		111	F8	F9	FA	FB	FC	FD	FE	FF
The [*] nomenclature means a disp32 with no base if the MOD is 00B. Otherwise, [*] means disp8 or disp32 + [EBP]. This provides the following address modes: MOD bits Effective Address 00 [scaled index] + disp32 01 [scaled index] + disp8 + [EBP] 10 [scaled index] + disp32 + [EBP]

Example 0.11. This instruction:

jmp [eax*2 + ebx]

generates the following code:

00000000 67 ff 24 43

First of all, the first byte, 0x67 is not an opcode but a prefix. The number is a predefined prefix for address-size override prefix. After the prefix, comes the opcode 0xff and the ModR/M byte 0x24. The value from ModR/M suggests that there exists a SIB byte that follows. The SIB byte is 0x43.

Look up in the SIB table, the row tells that eax is scaled by 2, and the column tells that the base to be added is in ebx.

Displacement

is the offset from the start of the base index.

Example 0.12. This instruction:

jmp [0x1234]

generates machine code is:

ff 26 34 12

0x1234, which is generated as 34 12 in raw machine code, is the displacement and stands right next to 0x26, which is the ModR/M byte.

Example 0.13. This instruction:

jmp [eax * 4 + 0x1234]

generates the machine code:

67 ff 24 85 34 12 00 00

• 0x67 is an address-size override prefix. Its meaning is that if an instruction runs a default address size e.g. 16-bit, the use of prefix enables the instruction to use non-default address size, e.g. 32-bit or 64-bit. Since the binary is supposed to be 16-bit, 0x67 changes the instruction to 32-bit mode.
• 0xff is the opcode.
• 0x24 is the ModR/M byte. According to table 3., the value suggests that a SIB byte follows, .
• 0x85 is the SIB byte. According to table Part \Roman{part}, the byte 0x85 can be destructured into bits as follow:

  SS		R/M			REG
  1	0	0	0	0	1	0	1

  The above values are obtained through the columns SS, R/M and finally the 8 column of REG respectively. The total bits combined into the value 10000101, which is 0x85 in hex value. By default, if a register after the displacement is not specified, it is set to EBP register, and thus the 6^th column (bit pattern 101) is always chosen. If the example uses another register:
  Example 0.14. For example:
  jmp [eax * 4 + eax + esi]
  the SIB byte becomes 0x86 instead of , which is in the 7^th column. Try to verify with the table Part \Roman{part} again.
• 34 12 00 00 is the displacement. As can be seen, the displacement is 4 bytes in size, which is equivalent to 32-bit, due to address-size override prefix.

Immediate

When an instruction accepts a fixed value, e.g. 0x1234, as an operand, this optional field holds the value. Note that this field is different from displacement: the value is not necessary used an offset, but an arbitrary value of anything.

Example 0.15. This instruction:

mov eax, 0x1234

generates the code:

66 b8 34 12 00 00

• 0x66 is operand-sized override prefix. Similar to address-size override prefix, this prefix enables operand-size to be non-default.
• 0xb8 is one of the opcodes for mov instruction.
• 0x1234 is the value to be stored in register eax. It is just a value for storing directly into a register, and nothing more. On the other hand, displacement value is an offset for some address calculation.

Opcode table

lists all possible opcodes of an assembly instruction.

Each table contains the following fields, and can have one or more rows:

Opcode

Instruction

Op/En

64/32-bit Mode

CPUID Feature flag

Description

Opcode

shows a unique hexadecimal number assigned to an instruction. There can be more than one opcode for an instruction, each encodes a variant of the instruction. For example, one variant requires one operand, but another requires two. In this column, there can be other notations aside from hexadecimal numbers. For example, /r indicates that the ModR/M byte of the instruction contains a reg operand and an r/m operand. The detail listing is in section 3.1.1.1 and 3.1.1.2 in the Intel's manual, volume 2.

Instruction

gives the syntax of the assembly instruction that a programmer can use for writing code. Aside from the mnemonic representation of the opcode, e.g. jmp, other symbols represent operands with specific properties in the instruction. For example, rel8 represents a relative address from 128 bytes before the end of the instruction to 127 bytes after the end of instruction; similarly rel16/rel32 also represents relative addresses, but with the operand size of 16/32-bit instead of 8-bit like rel8. For a detailed listing, please refer to section 3.1.1.3 of volume 2.

Op/En

is short for Operand/Encoding. An operand encoding specifies how a ModR/M byte encodes the operands that an instruction requires. If a variant of an instruction requires operands, then an additional table named “Instruction Operand Encoding” is added for explaining the operand encoding, with the following structure:

Op/En

Operand 1

Operand 2

Operand 3

Operand 4

Most instructions require one to two operands. We make use of these instructions for our OS and skip the instructions that require three or four operands. The operands can be readable or writable or both. The symbol (r) denotes a readable operand, and (w) denotes a writable operand. For example, when Operand 1 field contains ModRM:r/m (r), it means the first operand is encoded in r/m field of ModR/M byte, and is only readable.

64/32-bit mode

indicates whether the opcode sequence is supported in a 64-bit mode and possibly 32-bit mode.

CPUID Feature Flag

indicates indicate a particular CPU feature must be available to enable the instruction. An instruction is invalid if a CPU does not support the required feature.

In Linux, the command:

cat /proc/cpuinfo

lists the information of available CPUs and its features in flags field.

Compat/Leg Mode

Many instructions do not have this field, but instead is replaced with Compat/Leg Mode, which stands for Compatibility or Legacy Mode. This mode enables 64-bit variants of instructions to run normally in 16 or 32-bit mode.

MarginTable 3: Notations in Compat/Leg Mode

Notation	Description
Valid	Supported
I	Not supported
N.E.	The 64-bit opcode cannot be encoded as it overlaps with existing 32-bit opcode.

Description

briefly explains the variant of an instruction in the current row.

Description

specifies the purpose of the instructions and how an instruction works in detail.

Operation

is pseudo-code that implements an instruction. If a description is vague, this section is the next best source to understand an assembly instruction. The syntax is described in section 3.1.1.9 in volume 2.

Flags affected

lists the possible changes to system flags in EFLAGS register.

Exceptions

list the possible errors that can occur when an instruction cannot run correctly. This section is valuable for OS debugging. Exceptions fall into one of the following categories:

• Protected Mode Exceptions
• Real-Address Mode Exception
• Virtual-8086 Mode Exception
• Floating-Point Exception
• SIMD Floating-Point Exception
• Compatibility Mode Exception
• 64-bit Mode Exception

Words, doublewords, and quadwords do not need to be aligned in memory on natural boundaries. The natural boundaries for words, double words, and quadwords are even-numbered addresses, addresses evenly divisible by four, and addresses evenly divisible by eight, respectively. However, to improve the performance of programs, data structures (especially stacks) should be aligned on natural boundaries whenever possible. The reason for this is that the processor requires two memory accesses to make an unaligned memory access; aligned accesses require only one memory access. A word or doubleword operand that crosses a 4-byte boundary or a quadword operand that crosses an 8-byte boundary is considered unaligned and requires two separate memory bus cycles for access.

Some instructions that operate on double quadwords require memory operands to be aligned on a natural boundary. These instructions generate a general-protection exception (#GP) if an unaligned operand is specified. A natural boundary for a double quadword is any address evenly divisible by 16. Other instructions that operate on double quadwords permit unaligned access (without generating a general-protection exception). However, additional memory bus cycles are required to access unaligned data from memory.

Source

#include <stdint.h>

uint8_t byte = 0x12;
uint16_t word = 0x1234;
uint32_t dword = 0x12345678;
uint64_t qword = 0x123456789abcdef;
unsigned __int128 dqword1 =  (__int128) 0x123456789abcdef;
unsigned __int128 dqword2 =  (__int128) 0x123456789abcdef << 64;

int main(int argc, char *argv[]) {
        return 0;
}

Assembly

0804a018 <byte>:

804a018: 12 00 adc al,BYTE PTR [eax]

0804a01a <word>:

804a01a: 34 12 xor al,0x12

0804a01c <dword>:

804a01c: 78 56 js 804a074 <_end+0x48>

804a01e: 34 12 xor al,0x12

0804a020 <qword>:

804a020: ef out dx,eax

804a021: cd ab int 0xab

804a023: 89 67 45 mov DWORD PTR [edi+0x45],esp

804a026: 23 01 and eax,DWORD PTR [ecx]

0000000000601040 <dqword1>:

601040: ef out dx,eax

601041: cd ab int 0xab

601043: 89 67 45 mov DWORD PTR [rdi+0x45],esp

601046: 23 01 and eax,DWORD PTR [rcx]

601048: 00 00 add BYTE PTR [rax],al

60104a: 00 00 add BYTE PTR [rax],al

60104c: 00 00 add BYTE PTR [rax],al

60104e: 00 00 add BYTE PTR [rax],al

0000000000601050 <dqword2>:

601050: 00 00 add BYTE PTR [rax],al

601052: 00 00 add BYTE PTR [rax],al

601054: 00 00 add BYTE PTR [rax],al

601056: 00 00 add BYTE PTR [rax],al

601058: ef out dx,eax

601059: cd ab int 0xab

60105b: 89 67 45 mov DWORD PTR [rdi+0x45],esp

60105e: 23 01 and eax,DWORD PTR [rcx]

$ readelf -x .data hello

the output is (the colors mark which values belong to which variables):

Hex dump of section '.data':

0x00601020 00000000 00000000 00000000 00000000 ................

0x00601030 12003412 78563412 efcdab89 67452301 ..4.xV4.....gE#.

0x00601040 efcdab89 67452301 00000000 00000000 ....gE#.........

0x00601050 00000000 00000000 efcdab89 67452301 ............gE#.

As can be seen in the readelf output, variables are allocated storage space according to their types and in the declared order by the programmer (the colors correspond the the variables). Intel is a little-endian machine, which means smaller addresses hold bytes with smaller values, larger addresses hold byte with larger values. For example, 0x1234 is displayed as 34 12; that is, 34 appears first at address 0x601032, then 12 at 0x601033. The decimal values within a byte is unchanged, so we see 34 12 instead of 43 21. This is quite confusing at first, but you will get used to it soon.

Also, isn't it redundant when char type is always 1 byte already and why do we bother adding int8_t? The truth is, char type is not guaranteed to be 1 byte in size, but only the minimum of 1 byte in size. In C, a byte is defined to be the size of a char, and a char is defined to be smallest addressable unit of the underlying hardware platform. There are hardware devices that the smallest addressable unit is 16 bit or even bigger, which means char is 2 bytes in size and a “byte” in such platforms is actually 2 units of 8-bit bytes.

Not all architectures support the double quadword type. Still, gcc does provide support for 128-bit number and generate code when a CPU supports it (that is, a CPU must be 64-bit). By specifying a variable of type __int128 or unsigned __int128, we get a 128-bit variable. If a CPU does not support 64-bit mode, gcc throws an error.

The data types in C, which represents the fundamental data types, are also called unsigned numbers. Other than numerical calculations, unsigned numbers are used as a tool for structuring data in memory; we will this application see later in the book, when various data structures are organized into bit groups.

In all the examples above, when the value of a variable with smaller size is assigned to a variable with larger size, the value easily fits in the larger variable. On the contrary, the value of a variable with larger size is assigned to a variable with smaller size, two scenarios occur:

• The value is greater than the maximum value of the variable with smaller layout, so it needs truncating to the size of the variable and causing incorrect value.
• The value is smaller than the maximum value of the variable with a smaller layout, so it fits the variable.

However, the value might be unknown until runtime and can be value, it is best not to let such implicit conversion handled by the compiler, but explicitly controlled by a programmer. Otherwise it will cause subtle bugs that are hard to catch as the erroneous values might rarely be used to reproduce the bugs.

Pointer Data Types

Pointers are variables that hold memory addresses. x86 works with 2 types of pointers:

Near pointer

is a 16-bit/32-bit offset within a segment, also called effective address.

Far pointer

is also an offset like a near pointer, but with an explicit segment selector.

C only provides near pointer, since far pointer is platform dependent, such as x86. In application code, you can assume that the address of current segment starts at 0, so the offset is actually any memory addres from 0 to the maximum address.

Source

#include <stdint.h>

int8_t i = 0;
int8_t *p1 =  (int8_t *) 0x1234;
int8_t *p2 =  &i;

int main(int argc, char *argv[]) {
        return 0;
}

Assembly

0000000000601030 <p1>:

601030: 34 12 xor al,0x12

601032: 00 00 add BYTE PTR [rax],al

601034: 00 00 add BYTE PTR [rax],al

601036: 00 00 add BYTE PTR [rax],al

0000000000601038 <p2>:

601038: 41 10 60 00 adc BYTE PTR [r8+0x0],spl

60103c: 00 00 add BYTE PTR [rax],al

60103e: 00 00 add BYTE PTR [rax],al

Disassembly of section .bss:

0000000000601040 <__bss_start>:

601040: 00 00 add BYTE PTR [rax],al

0000000000601041 <i>:

601041: 00 00 add BYTE PTR [rax],al

601043: 00 00 add BYTE PTR [rax],al

601045: 00 00 add BYTE PTR [rax],al

601047: 00 .byte 0x0

The pointer p1 holds a direct address with the value 0x1234. The pointer p2 holds the address of the variable i. Note that both the pointers are 8 bytes in size (or 4-byte, if 32-bit).

Bit Field Data Type

Source

struct bit_field {
    int data1:8;
    int data2:8;
    int data3:8;
    int data4:8;
};

struct bit_field2 {
    int data1:8;
    int data2:8;
    int data3:8;
    int data4:8;
    char data5:4;
};

struct normal_struct {
    int data1;
    int data2;
    int data3;
    int data4;
};

struct normal_struct ns = {
    .data1 = 0x12345678,
    .data2 = 0x9abcdef0,
    .data3 = 0x12345678,
    .data4 = 0x9abcdef0,
};

int i = 0x12345678;

struct bit_field bf = {
    .data1 = 0x12,
    .data2 = 0x34,
    .data3 = 0x56,
    .data4 = 0x78
};

struct bit_field2 bf2 = {
    .data1 = 0x12,
    .data2 = 0x34,
    .data3 = 0x56,
    .data4 = 0x78,
    .data5 = 0xf
};

int main(int argc, char *argv[]) {
    return 0;
}

Assembly

Each variable and its value are given a unique color in the assembly listing below:

0804a018 <ns>:

804a018: 78 56 js 804a070 <_end+0x34>

804a01a: 34 12 xor al,0x12

804a01c: f0 de bc 9a 78 56 34 lock fidivr WORD PTR [edx+ebx*4+0x12345678]

804a023: 12

804a024: f0 de bc 9a 78 56 34 lock fidivr WORD PTR [edx+ebx*4+0x12345678]

804a02b: 12

0804a028 <i>:

804a028: 78 56 js 804a080 <_end+0x44>

804a02a: 34 12 xor al,0x12

0804a02c <bf>:

804a02c: 12 34 56 adc dh,BYTE PTR [esi+edx*2]

804a02f: 78 12 js 804a043 <_end+0x7>

0804a030 <bf2>:

804a030: 12 34 56 adc dh,BYTE PTR [esi+edx*2]

804a033: 78 0f js 804a044 <_end+0x8>

804a035: 00 00 add BYTE PTR [eax],al

804a037: 00 .byte 0x0

The sample code creates 4 variables: ns, i, bf, bf2. The definition of normal_struct and bit_field structs both specify 4 integers. bit_field specifies additional information next to its member name, separated by a colon, e.g. .data1 : 8. This extra information is the bit width of each bit group. It means, even though defined as an int, .data1 only consumes 8 bit of information. If additional data members are specified after .data1, two scenarios happen:

• If the new data members fit within the remaining bits after .data, which are 24 bits
  16

  Since .data1 is declared as an int, 32 bits are still allocated, but .data1 can only access 8 bits of information.
  , then the total size of bit_field struct is still 4 bytes, or 32 bits.
• If the new data members don't fit, then the remaining 24 bits (3 bytes) are still allocated. However, the new data members are allocated brand new storages, without using the previous 24 bits.

In the example, the 4 data members: .data1, .data2, .data3 and .data4, each can access 8 bits of information, and together can access all of 4 bytes of the integer first declared by .data1. As can be seen by the generated assembly code, the values of bf are follow natural order as written in the C code: 12 34 56 78, since each value is a separate members. In contrast, the value of i is a number as a whole, so it is subject to the rule of little endianess and thus contains the value 78 56 34 12. Note that at 804a02f, is the address of the final byte in bf, but next to it is a number 12, despite 78 is the last number in it. This extra number 12 does not belong to the value of bf. objdump is just being confused that 78 is an opcode; 78 corresponds to js instruction, and it requires an operand. For that reason, objdump grabs whatever the next byte after 78 and put it there. objdump is a tool to display assembly code after all. A better tool to use is gdb that we will learn in the next chapter. But for this chapter, objdump suffices.

Unlike bf, each data member in ns is allocated fully as an integer, 4 bytes each, 16 bytes in total. As we can see, bit field and normal struct are different: bit field structure data at the bit level, while normal struct works at byte level.

Finally, the struct of bf2

17

bit_field2

is the same of bf

18

bit_field

, except it contains one more data member: .data5, and is defined as an integer. For this reason, another 4 bytes are allocated just for .data5, even though it can only access 8 bits of information, and the final value of bf2 is: 12 34 56 78 0f 00 00 00. The remaining 3 bytes must be accessed by the mean of a pointer, or casting to another data type that can fully access all 4 bytes..

Exercise 0.4. What happens when the definition of bit_field struct and bf variable are changed to:

struct bit_field {

int data1:8;

};

struct bit_field bf = {

.data1 = 0x1234,

};

What will be the value of .data1?

Exercise 0.5. What happens when the definition of bit_field2 struct is changed to:

struct bit_field2 {

int data1:8;

int data5:32;

};

What is layout of a variable of type bit_field2?

String Data Types

Although share the same name, string as defined by x86 is different than a string in C. x86 defines string as “continuous sequences of bits, bytes, words, or doublewords”. On the other hand, C defines a string as an array of 1-byte characters with a zero as the last element of the array to make a null-terminated string. This implies that strings in x86 are arrays, not C strings. A programmer can define an array of bytes, words or doublewords with char or uint8_t, short or uint16_t and int or uint32_t, except an array of bits. However, such a feature can be easily implemented, as an array of bits is essentially any array of bytes, or words or doublewords, but operates at the bit level.

The following code demonstrates how to define array (string) data types:

Source

#include <stdint.h>

uint8_t a8[2] = {0x12, 0x34};
uint16_t a16[2] = {0x1234, 0x5678};
uint32_t a32[2] = {0x12345678, 0x9abcdef0};
uint64_t a64[2] = {0x123456789abcdef0, 0x123456789abcdef0};

int main(int argc, char *argv[])
{
    return 0;
}

Assembly

0804a018 <a8>:

804a018: 12 34 00 adc dh,BYTE PTR [eax+eax*1]

804a01b: 00 34 12 add BYTE PTR [edx+edx*1],dh

0804a01c <a16>:

804a01c: 34 12 xor al,0x12

804a01e: 78 56 js 804a076 <_end+0x3a>

0804a020 <a32>:

804a020: 78 56 js 804a078 <_end+0x3c>

804a022: 34 12 xor al,0x12

804a024: f0 de bc 9a f0 de bc lock fidivr WORD PTR [edx+ebx*4-0x65432110]

804a02b: 9a

0804a028 <a64>:

804a028: f0 de bc 9a 78 56 34 lock fidivr WORD PTR [edx+ebx*4+0x12345678]

804a02f: 12

804a030: f0 de bc 9a 78 56 34 lock fidivr WORD PTR [edx+ebx*4+0x12345678]

804a037: 12

Despite a8 is an array with 2 elements, each is 1-byte long, but it is still allocated with 4 bytes. Again, to ensure natural alignment for best performance, gcc pads extra zero bytes. As shown in the assembly listing, the actual value of a8 is 12 34 00 00, with a8[0] equals to 12 and a8[1] equals to 34.

Then it comes a16 with 2 elements, each is 2-byte long. Since 2 elements are 4 bytes in total, which is in the natural alignment, gcc pads no byte. The value of a16 is 34 12 78 56, with a16[0] equals to 34 12 and a16[1] equals to 78 56. Note that, objdump is confused again, as de is the opcode for the instruction fidivr (short of reverse divide) that requires another operand, so objdump grabs whatever the next bytes that makes sense to it for creating “an operand”. Only the highlighted values belong to a32.

Next is a32, with 2 elements, 4 bytes each. Similar to above arrays, the value of a32[0] is 78 56 34 12, the value of a32[1] is f0 de bc 9a, exactly what is assigned in the C code.

Finally is a64, also with 2 elements, but 8 bytes each. The total size of a64 is 16 bytes, which is in the natural alignment, therefore no padding bytes added. The values of both a64[0] and a64[1] are the same: f0 de bc 9a 78 56 34 12, that got misinterpreted to fidivr instruction.

Figure 0.13: a8, a16, a32 and a64 memory layouts

a8:  

12 | 34

a16:

34 12   | 78 56

a32:

78 56 34 12       | f0 de bc 9a

a64:

f0 de bc 9a 78 56 34 12               | f0 de bc 9a 78 56 34 12

However, beyond one-dimensional arrays that map directly to hardware string type, C provides its own syntax for multi-dimensional arrays:

Source

#include <stdint.h>

uint8_t a2[2][2] = {
    {0x12, 0x34},
    {0x56, 0x78}
};

uint8_t a3[2][2][2] = {
    {{0x12, 0x34},
     {0x56, 0x78}},
    {{0x9a, 0xbc},
     {0xde, 0xff}},
};

int main(int argc, char *argv[]) {
    return 0;
}

Assembly

0804a018 <a2>:

804a018: 12 34 56 adc dh,BYTE PTR [esi+edx*2]

804a01b: 78 12 js 804a02f <_end+0x7>

0804a01c <a3>:

804a01c: 12 34 56 adc dh,BYTE PTR [esi+edx*2]

804a01f: 78 9a js 8049fbb <_DYNAMIC+0xa7>

804a021: bc .byte 0xbc

804a022: de ff fdivrp st(7),st

Technically, multi-dimensional arrays are like normal arrays: in the end, the total size is translated into flat allocated bytes. A 2 x 2 array is allocated with 4 bytes; a $2\times 2\times 2$ array is allocated with 8 bytes, as can be seen in the assembly listing of a2

19

Again, objdump is confused and put the number 12 next to 78 in a3 listing.

and a3. In low-level assembly code, the representation is the same between a[4] and a[2][2]. However, in high-level C code, the difference is tremendous. The syntax of multi-dimensional array enables a programmer to think with higher level concepts, instead of translating manually from high-level concepts to low-level code and work with high-level concepts in his head at the same time.

Example 0.16. The following two-dimensional array can hold a list of 2 names with the length of 10:

char names[2][10] = {
    "John Doe",
    "Jane Doe"
};

To access a name, we simply adjust the column index

20

The left index is called column index since it changes the index based on a column.

e.g. names[0], names[1]. To access individual character within a name, we use the row index

21

Same with column index, the right index is called row index since it changes the index based on a row.

e.g. names[0][0] gives the character “J”, names[0][1] gives the character “o” and so on.

Without such syntax, we need to create a 20-byte array e.g. names[20], and whenever we want to access a character e.g. to check if the names contains with a number in it, we need to calculate the index manually. It would be distracting, since we constantly need to switch thinkings between the actual problem and the translate problem.

Since this is a repeating pattern, C abstracts away this problem with the syntax for define and manipulating multi-dimensional array. Through this example, we can clearly see the power of abstraction through language can give us. It would be ideal if a programmer is equipped with such power to define whatever syntax suitable for a problem at hands. Not many languages provide such capacity. Fortunately, through C macro, we can partially achieve that goal .

In all cases, an array is guaranteed to generate contiguous bytes of memory, regardless of the dimensions it has.

Exercise 0.6. What is the difference between a multi-dimensional array and an array of pointers, or even pointers of pointers?

Examine compiled code

This section will explore how compiler transform high level code into assembly code that CPU can execute, and see how common assembly patterns help to create higher level syntax. -S option is added to objdump to better demonstrate the connection between high and low level code.

In this section, the option --no-show-raw-insn is added to objdump command to omit the opcodes for clarity:

$ objdump --no-show-raw-insn -M intel -S -D <object file> | less

Data Transfer

Previous section explores how various types of data are created, and how they are laid out in memory. Once memory storages are allocated for variables, they must be accessible and writable. Data transfer instructions move data (bytes, words, doublewords or quadwords) between memory and registers, and between registers, effectively read from a storage source and write to another storage source.

Source

#include <stdint.h>

int32_t i = 0x12345678;

int main(int argc, char *argv[]) {
        int j = i;
        int k = 0xabcdef;

        return 0;
}

Assembly

080483db <main>:

#include <stdint.h>

int32_t i = 0x12345678;

int main(int argc, char *argv[]) {

80483db: push ebp

80483dc: mov ebp,esp

80483de: sub esp,0x10

int j = i;

80483e1: mov eax,ds:0x804a018

80483e6: mov DWORD PTR [ebp-0x8],eax

int k = 0xabcdef;

80483e9: mov DWORD PTR [ebp-0x4],0xabcdef

return 0;

80483f0: mov eax,0x0

}

80483f5: leave

80483f6: ret

80483f7: xchg ax,ax

80483f9: xchg ax,ax

80483fb: xchg ax,ax

80483fd: xchg ax,ax

80483ff: nop

The general data movement is performed with the mov instruction. Note that despite the instruction being called mov, it actually copies data from one destination to another.

The red instruction copies data from the register esp to the register ebp. This mov instruction moves data between registers and is assigned the opcode 89.

The blue instructions copies data from one memory location (the i variable) to another (the j variable). There exists no data movement from memory to memory; it requires two mov instructions, one for copying the data from a memory location to a register, and one for copying the data from the register to the destination memory location.

The pink instruction copies an immediate value into memory. Finally, the green instruction copies immediate data into a register.

Expressions