Assembler and System Software Fundamentals

13.1 Software Categories — System Software and Application Software

13.1.1 What Software Means in This Setting

A software item is a collection of computer programs that runs on a laptop or other computer. The same idea appears under different names such as tool, driver, or product, but the core stays the same: a program, which is an ordered list of instructions. Each instruction tells the computer what to do and how to do it — move data, add values, test a condition, jump to another spot.

The actor that carries out those instructions is the processor. In the lecture the processor was framed as a digital circuit designed to handle a set of instructions — hardware that only understands machine code built from its instruction set (the vocabulary it was manufactured to decode). Everything a programmer writes, whether in Python, C, or assembly, must eventually be translated to that machine-form vocabulary before the processor can act. That translation chain is the spine of this whole lecture.

One everyday illustration starts with $A=B+C$. Here $A$, $B$, and $C$ are three data items that live at different addresses. Bringing the value of $B$ and the value of $C$ uses a move operation. Adding them uses an add operation. Storing the sum into $A$ uses a store or assignment operation. This split between move, add, and store shows how a single line that looks simple to a person becomes several steps that the hardware can act on.

Visual intuition: picture a three-layer tower. Bottom layer is bare silicon — the processor and memory chips. Middle layer is a scaffold labeled "system software" that knows how to bolt memory, schedule time on the CPU, and talk to devices. Top layer is a set of colored tiles — Gmail, Excel, Paint — resting on the scaffold. The x-axis is abstraction (from hardware-close on the left to human-close on the right), the y-axis is who you interact with. The takeaway: tiles never float; remove the scaffold and nothing on top can stand.

Real-world and domain placement: every laptop you use today stacks these layers. When you double-click Excel, the operating system (system software) finds a free RAM region, and the translator chain (compiler → assembler → linker) has already converted Excel's source into the x86 or ARM binary your specific processor can decode. Systems programming lives in that middle scaffold — writing the very translators, loaders, and operating system pieces that make the top tiles possible.

13.1.2 Application Software — Programs Used to Produce an End Result

Application software is any software used in daily life to create a directly delivered result — something immediately useful outside the program itself. The discussion gave a set of concrete cases. A browser is used to browse the internet, watch videos, and open other web resources. A mailing system such as Gmail provides mail handling. A reader for PDF documents handles reading of documents. A drawing program such as MS Paint is used to create pictures. A presentation program such as PowerPoint is used to create slides. A suite such as Microsoft Office groups several such uses. The common trait is that the person opens the program to produce something that is immediately useful outside the program itself.

Visual intuition: imagine a market stall row. Each stall sells one finished good: one sells browsing, one sells mail, one sells PDF reading, one sells drawing. Customers walk to the stall for the good, not to admire the scaffolding behind it. Same row, different goods — that variety is the definition.

13.1.3 System Software — Programs that Operate the Hardware and Support Applications

System software is computer software designed to operate the computer hardware and to provide a platform for running application software. It works very closely with the hardware of the system.

13.1.4 How the Two Categories Relate

Application software needs system software whenever it is run. System software in turn runs on the hardware. The practical result is a layered view: hardware at the base, system software that knows how to use the hardware and that allocates resources, and application software that relies on that support to reach the user.

Picture the stack as: $$\mathcal{H}(\text{hardware})\to {\mathcal{S}}_{sys}(\text{OS, assembler, linker, loader, compiler, editor})\to {\mathcal{S}}_{app}(\text{browser, Gmail, Office, …})$$

Inline prose: each arrow is a dependency. ${\mathcal{S}}_{sys}$ translates and places code so $\mathcal{H}$ can run it; ${\mathcal{S}}_{app}$ requests services (memory, files, display) through ${\mathcal{S}}_{sys}$ and never touches $\mathcal{H}$ directly in normal operation. The next sections follow the chain that turns a program written by a person into a form the hardware can run, where the assembler is one of the key system tools.

Real-world and domain placement: in systems programming interviews and in OS coursework, you are routinely asked to place a new tool into this stack — "is a device driver application or system software?" — and to trace a C file from editor through compiler and assembler to the running process. Getting the layer wrong predicts getting the whole pipeline wrong, so this first distinction is examinable scaffolding, not background.

13.2 The Translation Chain — From Source Program to Executable

13.2.1 Source Program, Object Program, and Executable Code

A source program is the program as written, either in a high-level language or in assembly language — the human-readable text you edit. A translator converts that source into a lower form. After that step the result is called an object program. The object program is very close to the form that can run. It is close to a machine language program, but it is not yet linked to the other modules of the same program or to the library routines it calls. If the overall program is split into modules or makes library calls (for example printf), those links are still missing — the object file contains slots where the external addresses should be.

The linker joins the object code with its dependencies, whether they are other modules of the same program or library routines. After linking, the result is an executable code or executable program, which is ready to run on that machine in the sense that all symbols are resolved — but it still lives on disk. The loader, which is itself part of the operating system and is system software, then helps load the executable onto primary memory, the RAM. The loader knows where the executable file is present on storage, maps it to a free memory location in RAM, and puts it there for execution. Only after that mapping can the operating system perform process scheduling, which points the CPU at the first instruction of the program and asks the hardware to start the sequence.

Visual intuition: imagine an assembly line with four stations. Station 1 (translator) rewrites your text into machine-ish fragments on trays (object files). Station 2 (linker) bolts trays together and screws in library shelves. Station 3 (loader) carries the finished cabinet to an empty bay in a warehouse (RAM). Station 4 (scheduler) hands the worker the bay number and says "start at shelf 1." The x-axis is time through the build; the y-axis is completeness. The takeaway: each station adds a binding that earlier stations cannot provide.

13.2.2 Compilers, Assemblers, and Interpreters as Translators

Different source forms use different translators. A compiler takes a high-level program such as a C program and converts it to machine-level language. The description stressed that a compiler works on the whole program and produces the converted form in one shot, after which an exe-type file can be run — errors are reported together, optimization can look across the whole program. An interpreter instead works line by line. Python and the shell that runs shell scripts are the cases given. The interpreter converts a line to machine language and executes it, and when it meets an error it stops at that point — there is no separate exe, execution and translation interleave.

An assembler takes a program in assembly language and converts it to the lower form. In the overall flow that was sketched, a C program goes through a compiler to an assembly-language program, and that assembly program then goes through an assembler to an object program. The assembler step is why we study mnemonics like MOV — they are the vocabulary the compiler targets before the final binary is emitted.

A small flow recap expressed in words: high-level source such as C goes through a compiler to assembly language that contains the hardware-supported instructions. Those instructions use names such as MOV for move, IN for input, and ADD for add, but the machine can only understand zeros and ones. The assembler is then used to take that assembly-language program further down toward machine language. The object program that comes out is similar to machine language, and it still requires the linker to connect modules and library routines, producing the executable, which then requires the loader to get a place in memory.

Comparison — compiler versus interpreter versus assembler:

When to pick which: choose compiler/assembler when you need a reusable, optimizable binary; choose interpreter when you need immediate feedback and portability of source (not binary).

13.2.3 Why a Loader Matters and How Much Is Loaded

The loader is initiated when the executable is to be run. It takes the executable and maps it to a free region of RAM. A question that often arises is whether the whole program must be in memory at once. For small programs that do work such as adding two numbers, evaluating a quadratic, or generating a Fibonacci series, the whole program is small and is loaded as a unit and then runs — the cost of demand handling would exceed the savings.

For larger programs that run into gigabytes, the system does not need to keep everything resident. Modern systems can load only the parts that are needed at a moment, which helps with multitasking and with keeping several programs in memory. The principle is demand loading / paging: keep the working set in RAM, bring the rest on fault.

Visual intuition: picture RAM as a small stage that can hold 5 actors. A large play has 30 actors. Instead of crowding all 30 on stage for the whole show, the stage manager (OS + loader) brings on only the scene's cast. Excel's macro actors wait in the wings until the macro scene is called — then they walk on.

13.2.4 Student Questions and Answers on the Chain

Real-world and domain placement: in build systems (gcc → as → ld) and in DevOps (container images contain linked executables that a loader still must place), this chain is the daily pipeline. Systems programmers debug it directly — "undefined reference" is a linker complaint, "segfault at load" is a loader/placement complaint — so naming the right stage points to the right fix.

13.3 Hardware Platforms, Instruction Sets, and Why Executables Do Not Travel

13.3.1 Instruction Set Architecture Tied to the Processor

Each processor comes with its own instruction set architecture (ISA). That architecture defines which instructions the processor supports and can execute — the vocabulary plus the encoding, register set, addressing modes, and side effects. The examples given for mnemonics included MOV, IN, OUT, ADD, SUB, and MUL. The same program that is meaningful on one machine may be meaningless on another when the two machines do not share the same set of instructions, just as an English sentence is meaningless to a reader who only knows Hindi script.

13.3.2 x86 and ARM as Two Families

Two broad families were used as contrast.

Real-world: x86 appears in Windows laptops and many servers through Intel parts such as Pentium, dual core, Xeon, and the historical 8086 through 586 line. ARM appears in smart phones, many Android devices, and boards such as Raspberry Pi, with its own instruction set that differs from x86. A program compiled for one must be rebuilt for the other — there is no shortcut of "rename the file."

13.3.3 What Happens When an Executable Is Copied to a Different Family

A simple question was asked: a source program is turned into executable code on an x86 machine, where the executable runs with no problem. That same executable file is copied to an ARM machine and an attempt is made to run it there.

The answer stressed that this direct copy does not work. The executable built on x86 contains instructions confined to x86. An ARM processor cannot recognize those instructions and cannot run them. To run on the new hardware the source must again go through a translator that targets that platform, producing a new executable that fits the instruction set of that machine.

13.3.4 How Java Bytecode Differs From a Direct Executable

Java was presented as a contrast that often causes confusion. When Java source is built it is not turned into a directly runnable machine executable. It is turned into bytecode, which appears as a file with a .class extension. Bytecode by itself does not run directly on the hardware. To run, it needs a runtime environment. That runtime is the JRE, which runs a Java Virtual Machine, often shortened to JVM. The JVM is specific to the hardware. The JVM for a Linux machine matches that machine, the JVM for Windows on x86 matches that machine, and the JVM for ARM matches that machine. Because the JVM is present in a hardware-specific form, the same bytecode file can be carried to any of those JVMs and run there. In that run the JVM takes each bytecode instruction and translates it on the fly to the instruction form that the underlying hardware supports.

Visual intuition: picture two shipping strategies. C ships a finished chair built for door width $P$ — if the next house has door width $Q$ it does not fit. Java ships a flat-pack plus an on-site assembler (the JVM) who builds the chair to fit whatever door is there. Flat-pack travels; finished chair does not, unless you rebuild it.

13.3.5 Student Questions and Answers on Platform Dependence

Real-world and domain placement: this is why app stores ship multiple APKs or fat binaries (one build per ISA), why cloud builders do cross-compilation (--target aarch64-unknown-linux-gnu versus x86_64), and why "it works on my laptop" is a systems bug until you name the ISA you built for. In the domain of systems programming, ISA awareness is the first line of portability engineering.

13.4 Assembly Language — Mnemonics, Symbolic Operands, and Instruction Format

13.4.1 The Role of Assembly Language in the Chain

Assembly language sits between high-level source and machine zeros and ones. After a compiler has produced assembly, that assembly already uses the instructions the target hardware supports — it is already ISA-specific — but still in text form. The assembler then carries the translation further down. The machine itself can only understand binary, so names such as MOV cannot stay as text; they must have a numeric machine equivalent that the decoder was wired to recognize. That final text-to-number step is the assembler's core job, and this section names the two kinds of text it must convert.

Visual intuition: assembly is an architectural blueprint where rooms are labeled "kitchen" and "bedroom"; machine code is the same blueprint where every label has been replaced by GPS coordinates. A builder (the CPU) can only navigate by coordinates, but humans edit by names until the last moment.

13.4.2 Mnemonics, Also Called Operation Codes

A mnemonic is a short name that tells the processor what to do with the operands it is given. The same idea is also called an operation code, shortened to opcode. Cases named in the lecture included STL for store, LDA for load address, STA for store address, LDCH and STCH for load and store character, LDX for load X, TIX for test index, COMP for compare, JEQ for jump on equal, J for jump, and JSUB for jump to subroutine. Each processor family defines which mnemonics exist, through its instruction set architecture — you cannot invent FOO and expect a stock CPU to know it. The assembler converts each mnemonic to the machine language value that the hardware recognizes. That numeric value is often shown in hexadecimal in notes and tables before it is expanded to binary for the hardware, because hex is compact for humans and maps cleanly to bits (one hex digit = four bits).

13.4.3 Symbolic Operands and Why They Need Addresses

Along with the mnemonic, many instructions name a symbolic operand — a data variable or label given by name, such as $A,B,C$, or labels such as RETADR for return address, RDREC for the read-record subroutine, WRREC for the write-record subroutine, LENGTH for the length of the record, BUFFER for the buffer that holds characters, THREE, ZERO, ENDFIL for end-of-file handling, and CLOOP for the copy loop. The name by itself is not enough for the hardware. The processor has no dictionary for "RETADR" — it only knows numeric addresses. The assembler must turn the name into the equivalent machine address where the item lives, so the hardware can access the value at that address at run time.

Visual intuition: symbols are like contact names in your phone. You tap "Mom" — the phone dials a number. The name is for you; the number is for the network. SYMTAB is the phone's contact list, and the assembler's job is to replace every tapped name with the right number before handing the call to the network.

13.4.4 How an Assembly Instruction Is Built

An assembly instruction brings the two parts together. The opcode field holds the machine value for the mnemonic, and the address field holds the machine address for the symbolic operand. In the listings shown, an instruction such as STL RETADR becomes a pair $14_{16}$ followed by $1033_{16}$, where $1033_{16}$ is the address of RETADR. An instruction such as JSUB RDREC becomes $48_{16}$ followed by $2039_{16}$, where $2039_{16}$ is the address of the RDREC subroutine. An instruction such as LDA LENGTH becomes $00_{16}$ followed by $1036_{16}$. A compare such as COMP with zero uses $28_{16}$ with address $1030_{16}$, and a jump on equal to ENDFIL uses $30_{16}$ with $1015_{16}$. A simple jump to CLOOP uses $3C_{16}$ with $1003_{16}$. Each of those pairs is the proper machine instruction format that the hardware can step through — opcode says what, address says where.

13.4.5 Data Constants Need Internal Form Too

The source also contains data constants that may be given in decimal, hexadecimal, or binary form as written. All of those must be turned into the internal machine representation, which is binary. The text example for the symbolic constant EOF was shown as a character constant whose internal form is the hex bytes $45_{16}$ $4F_{16}$ $46_{16}$ spelling "EOF" in display code, later expanded to binary.

Real-world and domain placement: even when you never write assembly by hand, compilers emit it and debuggers show it. Reading 14 1033 as "store to RETADR" is the skill that lets you interpret a crash dump, a disassembly view, or an embedded system's hex listing — the same literacy that systems engineers use to bring up a new board before any high-level toolchain is fully working.

13.5 Core Functions of the Assembler — The Five Translation Steps

13.5.1 Overview

The assembler is asked to do five tasks in order to turn the assembly listing into the sequence of object codes that forms the object program. The discussion walked through these steps using the running example from the COPY program and the associated tables. Naming them first helps you see where each later detail slots in:

1. Convert mnemonic opcodes to machine equivalents.
2. Convert symbolic operands to machine addresses.
3. Build machine instructions in proper format.
4. Convert data constants to internal representation.
5. Write the object program and the assembly listing.

Steps 1, 3, 4, 5 are local to one line. Step 2 is global — it needs a name whose definition may be pages away — which is the difficulty flagged at the end of this section.

13.5.2 Step 1 — Convert Mnemonic Operation Codes to Machine Equivalents

The first job is to look at each mnemonic and place the machine language equivalent for that opcode. Using the OPTAB mapping above, STL maps to $14_{16}$, LDA maps to $00_{16}$, JSUB maps to $48_{16}$, COMP maps to $28_{16}$, JEQ maps to $30_{16}$, and J maps to $3C_{16}$. The slide's verbal anchor — "convert mnemonic operation codes to machine language equivalents" — was stated while pointing at pairs where the left column held STL, JSUB, LDA and the right columns held 14, 48, 00, emphasizing that the left side is for humans and the right side is for the decoder.

13.5.3 Step 2 — Convert Symbolic Operands to Machine Addresses

The second job is to replace each symbolic operand name with the address where that symbol lives. The cases used were RETADR at $1033_{16}$, ZERO at $1030_{16}$, THREE at $102D_{16}$, LENGTH at $1036_{16}$, BUFFER as the buffer area, RDREC at $2039_{16}$, WRREC at $2061_{16}$, CLOOP at $1003_{16}$, and ENDFIL at $1015_{16}$. In the instruction format this is the address field that follows the opcode byte. So STL RETADR becomes $14$ $1033$, JSUB RDREC becomes $48$ $2039$, LDA LENGTH becomes $00$ $1036$, COMP ZERO becomes $28$ $1030$, JEQ ENDFIL becomes $30$ $1015$, and J CLOOP becomes $3C$ $1003$. The lecture drew attention to how a symbolic name such as RETADR is not usable by the hardware until it is replaced by its numeric address — the name is a human convenience, the address is the machine requirement.

13.5.4 Step 3 — Build Machine Instructions in Proper Format

With the opcode value and the address value known, the assembler builds the full machine instruction in the format that the hardware expects. The format shown is opcode byte followed by address bytes, often described as one byte for the opcode and two or three bytes for the address in the illustrations that displayed three hex bytes per line such as $14$ $10$ $33$. The collection of those formatted instructions in order is the core of what will be written into the object program.

Visual intuition: step 3 is stamping a luggage tag. Left side is stamped with the action icon (opcode), right side with the destination room number (address). The tag always has the same two fields, in the same order, so the handler (CPU) knows where to look.

13.5.5 Step 4 — Convert Data Constants to Internal Representation

Data constants that were written in source as characters or numbers are expanded to the internal form. The example traced was EOF, where the written characters "EOF" become the internal hex string $45$ $4F$ $46$ and the corresponding binary pattern $010001010100111101000110_2$. The same idea applies to numeric constants that may be written in decimal in the source but must be stored as binary for the machine.

13.5.6 Step 5 — Write the Object Program and the Assembly Listing

After the previous steps the assembler writes two outputs. The object program is the ordered sequence of all the object codes, organized into records that the loader can later map into memory (Header, Text, End — detailed in the next section). The assembly listing shows four columns together: location, label, instruction including any assembler directive, and argument. In the sample listing the leftmost column gave the location such as $1000_{16}$, the next column gave the label such as COPY or CLOOP, the next column gave the instruction such as STL or LDA or an assembler directive such as START, and the last column gave the argument such as RETADR or LENGTH. Those four columns together are the listing that was shown beside the object codes — the human-readable audit trail where each line's translation can be checked.

13.5.7 A Note on Ordering and the Difficulty in Step 2

The discussion noted that every step except the second one can be handled by reading the source one line at a time and acting at once. Step 2 is the exception because an instruction may name a symbol that has not been defined yet in the reading order. That situation is called a forward reference, and it forces the assembler to take more than one pass over the source. The remaining sections explain that problem and the two-pass response.

Real-world and domain placement: modern toolchains (like gas or nasm) still conceptually do these five jobs; they just hide Pass 1/2 inside one invocation. Understanding the split helps you read the error messages: "undefined symbol" is a step-2/SYMTAB complaint, "invalid opcode" is a step-1/OPTAB complaint, and a wrong hex dump is usually a step-3 format mistake.

13.6 A Complete Assembly Example — The COPY Program with RDREC and WRREC

13.6.1 What the COPY Program Does at a High Level

The running illustration is a pseudo-code program that copies a record from an input device to an output device. It is structured as a main copy loop plus two subroutines. The main part is named COPY. Its logic is: save the return address, call the subroutine RDREC to read one record into a BUFFER, check the length of the record that was read, and then branch. If the length is zero the program calls WRREC to write an end-of-file marker. If the length is greater than zero it calls WRREC to write the record just read to the output. It then returns to the top of the copy loop, written as CLOOP, and repeats. When the overall copy work is done it loads the saved return address back and returns to whoever called COPY, which was described as a main program that called COPY as a routine.

Think of COPY as a foreman who never touches the material himself — he sends the reader crew, inspects what they brought, then sends the writer crew, and loops until there is no more material.

COPY:  save RETADR
CLOOP: call RDREC          // BUFFER ← input, LENGTH ← bytes read
       if LENGTH == 0 → ENDFIL path (write EOF marker, then finish)
       else           → call WRREC   // output ← BUFFER[0..LENGTH-1]
       goto CLOOP
ENDFIL: write EOF marker via WRREC
       restore RETADR, return

13.6.2 The Assembly Listing Frame for COPY

The listing frame shown has location, label, instruction, and argument — the classic four-column audit trail. The header line shown is COPY START 1000, where COPY is the program name, START is a pseudo-instruction, and $1000_{16}$ signals that the program begins at location $1000_{16}$. Following lines are of the form:

• location $1000_{16}$ label none instruction STL argument RETADR producing object $14$ $1033$
• location $1003_{16}$ label CLOOP instruction JSUB argument RDREC producing $48$ $2039$
• location $1006_{16}$ instruction LDA argument LENGTH producing $00$ $1036$
• location $1009_{16}$ instruction COMP argument ZERO with ZERO at $1030_{16}$ producing $28$ $1030$
• location $100C_{16}$ instruction JEQ argument ENDFIL with ENDFIL at $1015_{16}$ producing $30$ $1015$
• location $100F_{16}$ instruction JSUB argument WRREC producing $48$ $2061$
• another J instruction to CLOOP with $3C$ $1003$, and so on through the subroutines.

The same pattern repeats for the other mnemonics: LDA always shows $00_{16}$, STL always $14_{16}$, JSUB always $48_{16}$. The address field changes to match the argument name.

Exam note: expect a question that gives a similar listing (with START, a few real instructions, some BYTE/WORD/RESB lines, and END) and asks for the matching object code. The method is the five steps from the previous section plus the directive handling from the next.

13.6.3 RDREC — Reading a Record Into a Buffer

RDREC is a subroutine that brings one record from an input device into memory. The processor hardware contains fast memory elements called registers. In this program two registers are used, named $A$ and $X$. The description of RDREC proceeds as:

Clear $X$ and clear $A$ to zero. Both registers are set to $0$.

Enter a loop named RLOOP. Read one character from the input device, where the input device was illustrated as a keypad, into register $A$. So after the read, $A$ holds the next input character.

Decide whether the character marks the end of record. The end of record is shown as the value $00_{16}$ or by an $X$ marker in the teaching diagram. If the character is not the end marker, store that character into the BUFFER at the index held in $X$. In notation, ${\text{BUFFER}}_X=A$. Then increment $X$ by one, $X\leftarrow X+1$, so $X$ now points to the next free slot in the buffer for the next character.

Check whether $X$ is still less than the maximum length allowed. If $X<\text{MAXLEN}$ go back to RLOOP and fetch another character. If $X$ has reached the limit, fall out of the loop. At that point $X$ holds the count of characters that were stored, which is the length of the record. That value is written to the symbol LENGTH by store $X$ to LENGTH, often noted as STX LENGTH. Then return from the subroutine to the caller. The record itself now sits in BUFFER, and its length sits in LENGTH, and both will be used by the write side.

Visual intuition: BUFFER is a row of pigeonholes, $X$ is a sliding pointer. Each non-EOR character drops into the hole under the pointer, then the pointer slides right. When the stop card appears, you stop and count how far the pointer slid — that count is LENGTH.

13.6.4 WRREC — Writing the Buffer to the Output Device

WRREC is the mirror routine that takes what is in BUFFER and shows it on an output device, illustrated as a display. Its logic is:

Clear $X$ to $0$. So $X=0$ at entry.

Use a loop named WLOOP. Get the character from BUFFER indexed by $X$, so the character is ${\text{BUFFER}}_X$. Write that character from $X$ position to the output device. Then increment $X$, $X\leftarrow X+1$. Then check whether $X$ is still less than LENGTH. In symbols, if $X<\text{LENGTH}$ go back to WLOOP. This repeats so that the record is walked from the first character to the last, one position per iteration, until the whole record has been displayed.

13.6.5 How the Pieces Fit Together

Putting COPY, RDREC, and WRREC together gives a full path: COPY saves the caller return link, calls RDREC to fill BUFFER and LENGTH, examines LENGTH against zero, calls WRREC either with EOF or with the buffer contents, loops back to CLOOP, and when that outer work is done restores the return address and returns. The buffer that RDREC fills is the same buffer that WRREC reads, which is why the address of BUFFER appears in both subroutines and why the gap that was seen between the main code ending near $1039_{16}$ and RDREC starting at $2039_{16}$ was attributed to the space reserved for BUFFER between those addresses.

That gap is not wasted — it is the reservation for BUFFER itself (and nearby data like EOF, ZERO, RETADR, LENGTH). The assembler reserved it via RESB/RESW directives, so the loader later knows to leave that range uninitialized but allocated. The text records reflect the same gap: they are contiguous within each block and jump over the reserved area.

Visual intuition: draw COPY as a roundabout with three exits — exit 1 to RDREC (inbound lane fills BUFFER), exit 2 through a LENGTH checkpoint (0 → EOF branch, >0 → data branch) to WRREC (outbound lane drains BUFFER), and a loopback arrow to CLOOP. BUFFER sits at the center island, touched from both sides.

13.6.6 Student Question on the Subroutines

Real-world and domain placement: this read-buffer-write pattern is the skeleton of every copy utility (cp, dd), every network proxy (read from socket, write to socket), and every embedded sensor loop (read ADC into buffer, process, write to UART). The register names change (ARM uses R0–R12), but the indexed-buffer plus length-exchange idiom is the portable core that systems code reuses.

13.7 Assembler Directives — Pseudo-Instructions that Guide the Assembler

13.7.1 What Directives Are

Assembler directives are also called pseudo-instructions. The wording "pseudo" was explained as meaning "false" instruction. They are not instructions that the processor will execute. Instead they give information to the assembler itself that helps the assembler carry out the translation — where to start, where to stop, how many bytes to set aside, what constant to pre-fill. Because they are not processor instructions they are not turned into machine language opcodes. The actual instructions are still the mnemonics such as STL, LDA, and JSUB, while the directives sit among them and steer the handling of addresses and data. Think of them as stage directions to the translator, not lines spoken by the actor.

13.7.2 START and END Mark the Program Boundaries

START tells the assembler that the assembly program starts at a particular place. A listing line such as COPY START 1000_{16} was shown, where $1000_{16}$ is the address where the program begins. The value for the location counter is tied to the START operand. END marks where the end of the program occurs and signals the assembler that there are no more lines to process. In the listings the first line uses START and there is a single END near the close of the whole source, with the understanding that even when only a fragment is shown the END would be present for a full program.

13.7.3 BYTE — Generate Character or Hexadecimal Constants

BYTE directs the assembler to generate a character or hexadecimal constant that occupies as many bytes as needed to represent the constant as written. Syntax in SIC:

• C'EOF' → three characters → three bytes 45 4F 46 (ASCII/display codes for E,O,F).
• X'F1' → hex pair F1 → one byte F1.
• X'05' with odd digits may be padded per implementation — the lecture noted each BYTE line is handled the same way: write exactly the bytes the constant denotes.

In the listing that was examined, BYTE appears as a directive in the instruction column with a constant as its argument, and the effect is that the given characters are expanded to their internal hex and binary bytes. The same directive was shown repeated to underline that each BYTE line is handled in the same way — one BYTE per constant, each contributing its bytes to the next Text record.

13.7.4 WORD — Generate One Word Integer Constant

WORD directs the assembler to generate one word integer constant. Where BYTE works by the byte, WORD groups several bytes together to form one word. The width used in the discussion was that a byte is eight bits, while a word is sixteen bits made from several bytes together — in SIC the standard word is three bytes (24 bits), and the lecture simplified to "word is several bytes, in the illustration sixteen bits." When WORD appears in the instruction column its argument is taken as an integer constant for that word. Example: THREE WORD 3 → value $3_{10}=000003_{16}$ as a three-byte word 00 00 03, which occupies one word in the object and advances LOCCTR by the word size.

13.7.5 RESB and RESW — Reserve Space Without an Initial Value

RESB stands for reserve byte. It directs the assembler to reserve the indicated number of bytes for the data named by the label on that line. RESW stands for reserve word. It directs the assembler to reserve the indicated number of words for the data, where each word is several bytes. So if a line gives a label and RESB 1, one byte is set aside; if it gives a label and RESW 1, one full word (three bytes in SIC, described as sixteen bits in the simplified width used by the illustration) is set aside. The discussion used these to explain how BUFFER and similar areas get space.

13.7.6 How Directives Appear in the Four Column Listing

In the four-column listing the directive appears where an instruction would appear. For example a line may show a location, then a label such as BUFFER, then a directive such as RESB, then an argument such as a numeric count. The same column layout is shared with real instructions such as LDX or LDA, and the assembler distinguishes the two cases: when the middle column holds a directive the line controls allocation or boundaries, when it holds a true opcode the line will produce a machine code byte.

Real-world: byte and word widths described here match the way memory allocation directives are used to size character buffers and integer work areas that the later execution will read and write. Sizing matters — a RESB 4096 that is too small truncates long records silently, while one that is too large wastes RAM but is harmless.

Visual intuition: directives are the architect's notes on the blueprint — "leave this many meters empty," "pour concrete here with this mix." The notes never become a wall themselves, but they shift where every later wall stands.

Real-world and domain placement: every ISA's assembler has the same directive family under different names (.byte, .word, .space, .org in GNU as; DB, DW, RESB in NASM). Recognizing "this line is a directive, not an instruction" is the first step to reading any disassembly or linker map in systems work.

13.8 The Object Program — Header, Text, and End Records

13.8.1 Why the Object Program Needs Records

After assembly the collection of object codes must be written in a form that the linker and the loader can use. That form is the object program, and it is organized into three types of records: a header record, one or more text records, and an end record. Each record type has a fixed column pattern that indicates its meaning, its addresses, and its content. The record structure is the handoff contract between assembler, linker, and loader — it answers "what, where, how long, and where next" for every chunk.

13.8.2 Header Record — Name, Starting Address, and Length

The header record carries an overview of the program. Column 1 holds the letter $H$ indicating a header record. Columns 2 to 7 hold the program name, six bytes in the design that was illustrated. The sample name COPY, written as C O P Y, fits inside those six bytes with room to spare. The discussion noted that while the sample design uses six bytes for the name, modern practice lets names be longer, up to 255, so the design shown is tied to the sample program.

Columns 8 to 13 hold the starting address, again six bytes expressed in hex. For the COPY work the starting address is $1000_{16}$, which appears in the record as 00 10 00 in hex display as 001000. That value comes directly from the operand of the START line COPY START 1000, where $1000_{16}$ was the value after START for the location counter.

Columns 14 to 19 hold the length of the object program in bytes, written in hexadecimal. In the sample that header displayed the length as 00 10 7A${}_{16}$, that is 00107A${}_{16}$. Put together the header looks like a single line that starts with $H$, then carries the name field with COPY, then 001000, then 00107A. Using the textbook's figure (R7 Fig. 2.3a compact form: HCOPY 00100000107A), the same fields are present with visual separators added for reading. The earlier miscounting of column widths noted in class comes from remembering that each field size already includes the counting offset: 2 to 7 is $7-2+1=6$ bytes, 8 to 13 is $13-8+1=6$, and 14 to 19 is $19-14+1=6$, so the line length of 19 is consistent.

13.8.3 Text Records — The Ordered Object Codes With Their Addresses

A text record carries part of the actual translated code. Column 1 holds the letter $T$ indicating a text record. Columns 2 to 7 hold the starting address in this record, in hex. Columns 8 to 9 hold the length of the object code in this record in bytes, also in hex. Columns 10 to 69 hold the object code itself.

In the worked illustration the first text record after the header started at address 001000 and showed length $1E_{16}$. The value $1E_{16}$ expands to decimal as $1\times 16+14=30_{10}$ bytes, which matches ten instructions at three bytes each. The object bytes in that record included ten successive codes such as 14 10 33, 48 20 39, 00 10 36, and so on, in that order. The next record started where that one ended. Adding the start and the length gives the new start: $001000_{16}+1E_{16}=00101E_{16}$. That next record showed length $15_{16}$, which is $1\times 16+5=21_{10}$ bytes, again holding its next group. Adding once more, $00101E_{16}+15_{16}=001033_{16}$, though the illustration noted that the address stream as shown jumps to 002039${}_{16}$ for the next group because the intervening locations are not text but are taken by the BUFFER area that sits between the end of the main COPY code near $1039_{16}$ and the start of the RDREC subroutine at $2039_{16}$. After the jump, the pattern continues: start 002039${}_{16}$ plus length $1E_{16}$ gives 002057${}_{16}$, and start 002057${}_{16}$ plus length $1C_{16}$ gives 002073${}_{16}$, each group holding its next ten codes until the program reaches the area for WRREC at $2061_{16}$. That interleaving shows that a text record is not only the contiguous run of instructions; it is also interrupted where directives reserve space.

Best-practice visual from the lecture: the slide wrote column 1 is T, 2 to 7 starting address in this record, 8 and 9 length in bytes, 10 to 69 object code and traced adding $1E_{16}$ to $1000_{16}$ to reach $101E_{16}$, then adding $15_{16}$ to that to reach the next start, and later aligning $2039_{16}+1E_{16}=2057_{16}$ and $2057_{16}+1C_{16}=2073_{16}$. Following that addition trail is the fastest way to verify a Text dump on the exam.

Another useful identity that was traced: the length of the object code in a record that holds ten three-byte instructions is $10\times 3=30_{10}$ bytes, which written in hex is $1E_{16}$ because $30_{10}=1\times 16+14$. That conversion from decimal byte count to hex length appears directly in the 8 to 9 columns, and the reverse — hex $1E\to 30$, hex $15\to 21$, hex $1C\to 28$, hex $07\to 7$ — was drilled.

Visual intuition: a Text record is a moving van's manifest: "van leaves warehouse at address $A$, carries $L$ bytes, here they are in order." The loader parks each van at its stated address. The BUFFER gap is an empty lot the assembler flags as "reserved — do not park, but do not build over."

13.8.4 End Record — Where Execution Begins

The end record marks the close of the object program and indicates where execution should start. Column 1 holds the letter $E$. Columns 2 to 7 hold the address of the first executable instruction, in hex. For COPY that address is $001000_{16}$, the same value that appeared in START and in the header. So the end line appears as $E$ followed by $001000$. Written fully it is a short line such as $E$ $001000$, with the understanding that the address field is six hex digits as in the header. The loader reads this to initialize the program counter; without it the OS would not know which address to jump to.

13.8.5 Putting Header, Text, and End Together

Taken together the object program appears as a file with a single header line beginning with H, several text lines each beginning with T and giving its own starting address and byte count and the hex bytes, and a single end line beginning with E with the entry address. The discussion showed a compact listing that uses the field demarcations H T T T T T E in that order — header, five-ish text groups covering main code, the gap, RDREC, WRREC, and the final tail, then end — which is the same ordering seen in inner sections of the teaching figure (R7 Fig. 2.3).

13.8.6 Worked Example of Record Fields

One worked group was matched line by line:

• Header $H$ COPY $001000$ $00107A$ from col 1 $H$, cols 2–7 name COPY, 8–13 start 001000, 14–19 length 00107A.
• Text $T$ $001000$ $1E$ followed by ten object codes each three bytes beginning 14 10 33, 48 20 39, and so on through the main loop.
• Text $T$ $00101E$ $15$ continuing the code.
• Gap for BUFFER explaining the jump in addresses from near $1039$ to $2039$.
• Text $T$ $002039$ $1E$, then $T$ $002057$ $1C$, then $T$ $002073$ continuing through RDREC and WRREC.
• End $E$ $001000$ giving the first executable instruction address $1000_{16}$.

Each hex byte in those records, where a byte holds two hex digits and each hex digit maps to four binary bits, is what the loader finally expands to binary for placement in RAM.

Real-world and domain placement: modern executables (ELF on Linux, PE on Windows, Mach-O on macOS) still carry the same ideas under different names — header with entry point, section table with virtual addresses and file lengths, then raw section bytes. The SIC H/T/E letters are pedagogical simplifications; the concepts (address, length, entry point, gap for bss) are exactly what readelf -h and objdump show.

13.9 Forward References and the Need for Two Passes

13.9.1 What Counts as Forward and Backward

A forward reference is a symbolic operand that names a label whose definition appears later in the source order — the use precedes the definition. A backward reference names a label that has already been defined earlier — the definition precedes the use.

In the COPY listing the instruction STL RETADR at location near $1000_{16}$ names RETADR that lives at $1033_{16}$. That name has not been seen when the line is first read, so it is a forward reference. Similarly JSUB RDREC names RDREC at $2039_{16}$ while still at the early part of the file, LDA LENGTH names LENGTH at $1036_{16}$, and the later COMP and JEQ lines name ZERO and ENDFIL before those symbols have been met. All of those are forward references — the assembler meets the need before the supply.

By contrast a jump such as J CLOOP at location near $1012_{16}$ points back to CLOOP at $1003_{16}$. That target has already been seen, so it is a backward reference and the address is already known when the line is scanned. Backward references never block a one-pass translator; forward references always do until extra bookkeeping is added.

13.9.2 Why Step 2 Is the Hard Step

The five assembler tasks were recalled: 1 convert mnemonics to values, 2 convert symbolic operands to addresses, 3 build formatted instructions, 4 convert constants, 5 write the object program and listing. All of those except step 2 can be handled by a straight sequential scan that reads one line at a time and acts immediately — mnemonics are in OPTAB already, formats are known, constants convert locally, and the listing can be written line by line.

Step 2 cannot, because a forward reference needs a label that the sequential scan has not met. The assembler does not know where RDREC lives when it first sees JSUB RDREC, so it cannot fill the address field at that moment. It could leave a hole and hope to patch it, but without a second scan it would have to know how far ahead to look — and that distance depends on directives like RESB 4096 that shift everything.

Visual intuition: imagine copying a book where footnotes refer to page numbers that have not been numbered yet. You cannot fill "see page 47" until you have paginated the whole book. Forward references are exactly those future-page footnotes — step 2 is the footnote-filling step.

13.9.3 The Two Pass Response

To solve that problem the assembler makes two passes over the source. The idea stated was: pass one notes all label definitions and assigns addresses to them, so that by the close of the first pass every label has a known address including the ones that were forward at first sight. Pass two is the actual translation pass, forming object codes and writing the listing, where the address that was missing in the first encounter is now filled in because the table already holds the future definition. That is why the assembler for this class is called a two-pass assembler. One pass collects the future, the second pass fills the blanks.

Real-world and domain placement: the forward-reference idea generalizes beyond assemblers — single-pass compilers must also forward-declare functions (int foo(); in C) or make two passes over declarations, and linkers perform a similar "collect symbols then resolve" loop across object files. Recognizing "this needs a definition that is not yet seen" is the systems diagnosis for why a tool needs another pass or a fixup table.

13.10 The Two-Pass Assembler — What Pass 1 and Pass 2 Do

13.10.1 What Is a Pass

A pass is one full read over the source program from the first line to END. The two-pass assembler does that work twice, with different roles for each sweep.

• Pass 1 is the address-collecting pass. It assigns a location to every line and remembers where every label landed.
• Pass 2 is the code-emitting pass. It uses the remembered locations to stamp the final bytes.

The work that was just described for forward references is the driver for this separation — without it, Pass 2 would have holes where forward symbols belong.

Visual intuition: Pass 1 is surveying land and planting numbered stakes (addresses) at every named lot (label). Pass 2 is the building crew that, now that every lot is staked, pours concrete at the staked positions using the right mold (opcode) for each lot.

13.10.2 Pass 1 — Assign Addresses and Save Label Values

Pass 1 has three main tasks. First, it assigns addresses to all statements in the program. That is done by stepping the location counter line by line. Second, it saves the values assigned to all labels for use in pass two, which is the collection into SYMTAB. Third, it does the early handling of assembler directives that affect sizing: for a directive such as BYTE it reserves the right number of bytes, for WORD it reserves a word, for RESB it reserves the indicated bytes, for RESW it reserves the indicated words, and for START it sets the beginning address.

The output of pass 1 is an intermediate file that records the per-line address that was assigned plus the label-to-value mapping. That intermediate file becomes the input to pass two. OPTAB and SYMTAB are the two tables that pass one consults and creates: OPTAB is read to know the size of each true machine instruction when bumping the location counter, and SYMTAB is written to remember every label and its address.

13.10.3 Pass 2 — Generate the Assembly and Finish the Program

Pass 2 walks the intermediate file. It takes the symbols that were collected and now gives them their numeric values inside the address fields. It assembles each instruction into its machine bytes, generates the data values for BYTE, WORD, and allied directives that need a value, finishes the handling of any assembler directive work that was not closed in pass one, and finally writes the object program in the H/T/E record form plus the four-column assembly listing that shows location, label, instruction or directive, and argument for each line.

13.10.4 Flow That Connects the Two Passes

The flow that was shown is: source program enters pass one, which consults OPTAB and SYMTAB while it creates an intermediate file. That intermediate file enters pass two, which generates values for the symbols, resolves the operand fields, and emits the object code.

In tabular form:

Each pass contributes one table role: OPTAB is static and holds the mnemonic-to-machine-value mapping for the processor, SYMTAB is built in pass one and consumed in pass two to replace symbolic names with numeric addresses.

Visual intuition: Pass 1 is a census taker who walks every street, writes each house number on a map (intermediate file) and logs "Mom lives at 1033" (SYMTAB). Pass 2 is the mail carrier who, map and address book in hand, delivers the correct stamped envelope to each house without ever knocking to ask "where do you live?"

13.10.5 Why Two Passes Are Enough Here

Because every forward reference becomes a known label by the end of the first sweep, the second sweep no longer needs to look ahead. Every address field can be filled immediately, including those that were blank the first time through. No third pass is needed under the lecture's assumptions: one definition per label, no nested forward-dependent expressions that would change LOCCTR after SYMTAB is built, and no relocation that would alter addresses after assembly. In richer assemblers with literal pools or forward-dependent EQU expressions, more passes or fixup tables may be needed — but for the SIC COPY program, two passes close every gap.

Real-world and domain placement: the "collect then fill" pattern appears far beyond assemblers — compilers collect declarations then emit code, linkers collect defined symbols then patch references, and even make collects dependencies then builds. Recognizing when a problem is "future information needed" tells you whether a second pass or a fixup table will be required, which is a routine design decision in systems tools.

13.11 Data Structures for Assembly — OPTAB, SYMTAB, and LOCCTR

13.11.1 OPTAB — The Operation Table

OPTAB is the operation table. It is a static table. It holds every mnemonic code defined for the processor, taken from the instruction set architecture, and for each mnemonic it gives the machine language equivalent and, when the processor has a variable-length instruction format, the length of that instruction. A small view that was shown includes: STL whose machine equivalent is $14_{16}$, LDA whose equivalent is $00_{16}$, JSUB whose equivalent is $48_{16}$, and analogs for COMP at $28_{16}$, JEQ at $30_{16}$, and J at $3C_{16}$. For a processor with variable-length instructions the entry also records the instruction length so the assembler knows how many bytes to advance.

The table is organized as a hash table with the mnemonic operation code as the key. The reason given is efficiency. Hundreds of mnemonics exist in an instruction set. Comparing each mnemonic in turn against every entry would be slow for every line — $O(n)$ per lookup with $n$ in the hundreds, times thousands of source lines. Instead the assembler runs the mnemonic through the hash, gets the bucket that should hold the opcode, and picks the value from that slot in expected $O(1)$ time. So on seeing "JSUB" it uses the hash to reach the bucket for JSUB and takes $48_{16}$, and on seeing "LDA" it takes $00_{16}$. That design is what makes the per-line translation of step 1 stay fast even when the table is large. Because the instruction set for a processor does not change while the source is being assembled, the table can be static for the entire run — built when the assembler itself is written, not rebuilt per program.

13.11.2 SYMTAB — The Symbol Table

SYMTAB is the symbol table, sometimes also called the symbol sync table in speech. It stores all the symbols, which are the various labels encountered in the program. Labels such as COPY, FIRST, CLOOP, ENDFIL, EOF, THREE, ZERO, RETADR, LENGTH, BUFFER, RDREC, and WRREC were listed as the kind of names that go there. Each entry holds a name and a value, where the value is the address where that label appears. Flags for error conditions are also kept alongside the name and value, in the sense used for the flag register that indicates overflow or a negative result; those flags can record conditions that arise during assembly (for example a symbol defined in two different places — duplicate label) and can be consulted when deciding how to handle a use of the symbol. Some implementations also keep type/length info for the labeled area.

The table is organized as a hash table as well, for the same efficiency reason. It helps both inserting a new label when it is first seen in pass one and retrieving the address for that label when it is needed as an operand in pass two. The per-line cost stays low because the hash brings the assembler directly to the neighborhood where the symbol is stored, rather than scanning the whole collection.

13.11.3 LOCCTR — The Location Counter

Mathematical trace: starting from $\text{LOCCTR}=1000_{16}$, a three-byte instruction advances it as $1000_{16}+3=1003_{16}$, another three-byte instruction makes $1003_{16}+3=1006_{16}$, and so on. When a reserved area is met, such as a BUFFER that occupies many bytes between the end of the main code near $1039_{16}$ and the next routine at $2039_{16}$, the same rule applies: LOCCTR is advanced by the size that was reserved, which accounts for the jump in the address stream that is seen when reading the text records.

13.11.4 How the Three Work Together

In pass one, LOCCTR assigns the address, OPTAB tells how many bytes a true instruction needs so LOCCTR can be advanced by the right amount, and SYMTAB records the address that was just given to any label (label value = current LOCCTR). In pass two, SYMTAB supplies the address for every operand name, OPTAB again supplies the opcode byte, and LOCCTR is not the driver any longer because the addresses are already recorded; instead OPTAB and SYMTAB together convert each intermediate line into the final machine bytes that go to the T records. One variable (LOCCTR) creates the map in the first pass; two tables (OPTAB static, SYMTAB built) replay the map in the second.

13.11.5 Student Questions on the Tables

Real-world and domain placement: these three structures survive in every modern assembler and compiler — LLVM's MCInstrInfo is OPTAB, its symbol table is SYMTAB, and the assembler's section offset is LOCCTR under another name. Debugging "duplicate symbol" or "invalid instruction" means consulting exactly the flags and lookups described here, and the hash-table reasoning is the same data-structures argument used for any high-frequency dictionary in systems code.

Exam Guidance Summary

The lecture included several points that map directly to how study and assessment are framed. This appendix collects them in one place so you can check each before the exam and before the assignment demo.

Practical tip from the lecture: for the object-code question, bring familiarity with hex counting for text-record lengths such as $1E_{16}=30_{10}$ and $15_{16}=21_{10}$, and with how the start address $1000_{16}$ advances by adding each line's length. For the shell work, be ready to walk through the commands, the special variables (like \$?, \$#, \$*, \$@), and how errors or exit cases are handled — that is what the demo dialogue will probe.

Key Industry Applications

• Computer as hardware family (x86). Intel-based x86 parts — including 8086 and the numbered line through 586 Pentium, then dual core and Xeon — keep the same architecture label and share an instruction set under the x86 banner. Real-world: a Windows laptop and many servers present the same kind of native executable that runs only on that family. A build farm that compiles for x86 laptops must use an x86-targeting toolchain; cross-compiling to ARM without switching the target produces a file that will fault on the laptop.

• ARM family in phones and small boards. An ARM-based phone, Android systems on ARM, and a board such as Raspberry Pi use a different instruction set with a different encoding. An x86 executable copied to ARM will not be recognized — the CPU raises an illegal-instruction fault — which is why the same C source must be translated again with an ARM-targeting compiler/assembler to produce a new binary. Real-world: mobile CI routinely builds two APK/ELF variants (x86 and ARM) from one source tree; embedded teams keep separate gcc-arm and gcc-x86 toolchains.

• Java portability through a virtual machine. A Java class file contains bytecode (*.class), not a direct executable, and that bytecode travels to any machine that has a matching JVM. The JVM is part of the JRE and is specific to the hardware — a Linux x86 JVM, a Windows x86 JVM, and an ARM JVM are different binaries that each translate the same bytecode to their own instruction set on the fly at run time. Real-world: enterprise servers, Android apps, and Raspberry Pi Java programs can share the same .class distribution because the per-device JVM does the final translation; the cost is the JVM must be installed and the run-time translation step.

• Partial program loading and demand paging. A large suite such as Microsoft Excel keeps many features in the same install, yet a rarely used facility such as macros may stay out of primary memory until the user starts it, at which point its code is loaded and then run. That demand-loading pattern — keep the working set resident, fault in the rest — lets the OS keep many programs alive on limited RAM and supports multitasking without forcing whole gigabyte programs to stay resident. By contrast small programs such as a few-line C program that adds two numbers, evaluates a quadratic, or walks a Fibonacci sequence are small enough to be loaded as a whole; demand handling would add overhead for no gain.

• Systems programming as a practice. Shell programming and the use of the many commands and special variables covered earlier are systems-programming tasks that sit beside assembler and loader work. The tools named for the trade — assemblers, linkers, loaders, compilers, editors, and drivers — together take a source program through object program to executable and then to a placed image in memory. Real-world: a systems engineer writes a shell script to automate a build, an assembler patch to bring up a new board before the compiler is ready, a linker script to place firmware at a fixed flash address, and a loader tweak to support demand paging — all links of the same chain.