ASM0010

At its core, data transfer in assembly is about moving values around so the CPU can work with them. 

The processor itself can only operate on data that’s in the right place, usually a register, so most assembly programs spend a lot of time copying values between:

Registers (inside the CPU)

Memory (RAM)

The stack (a special area of memory used for function calls and temporary storage)

Nothing “magical” happens during data transfer. The CPU simply copies bits from one location to another. Understanding where data comes from and where it goes is the foundation of everything else in assembly.

The Three Basic Data Transfer Instructions

MOV

Copies data from a source to a destination

Does not modify the original source

Does not perform calculations

Think of MOV as a straight copy-paste operation.

PUSH

Places a value onto the stack

Automatically adjusts the stack pointer

POP

Removes a value from the stack

Stores it somewhere (usually a register)

Automatically adjusts the stack pointer back

Together, PUSH and POP are essential for function calls, saving registers, and managing temporary data.

Operand Types: What Instructions Work With

Every assembly instruction operates on operands. An operand is simply the thing the instruction uses or modifies.

There are three basic operand types in x86 assembly:

1️⃣. Immediate Operands

Immediate operands are literal values written directly in the instruction.

Examples:

• 10

• -255

• 0FFh

Here, 10 is not stored in memory or a register beforehand—it’s embedded directly in the instruction.

Why this matters:

Immediate values are fast and convenient, but they’re fixed constants. You can’t change them at runtime.

2️⃣. Register Operands

Register operands refer to CPU registers, such as:

• EAX

• EBX

• ECX

• EDX

Registers are:

• Extremely fast

• Very limited in number

• Where almost all real computation happens

Key idea:

If the CPU is going to do math or logic, the data usually has to be in registers first.

3️⃣. Memory Operands

Memory operands reference locations in RAM.

Memory is:

• Much larger than registers

• Slower to access

• Where most program data lives long-term

Assembly forces you to be explicit about memory access. 

You never “accidentally” touch memory, you have to say exactly where.

ADDRESSING MODES: HOW MEMORY IS REACHED

When an instruction refers to memory, the CPU needs to know how to find that memory address. This is where addressing modes come in.

1. Direct Addressing

Direct addressing specifies the memory location explicitly.

What this means:

myValue represents a fixed memory address

The CPU goes directly to that address and reads the value

Key characteristics:

The address is fixed

Very clear and readable

Mostly used with labels and global variables

In real programs, direct addressing is common when working with named data defined in the data segment.

2. Immediate Addressing (Not Memory!)

Immediate addressing does not access memory at all.

What’s happening:

The value 10 is placed directly into EAX

No memory lookup occurs

This is included here because beginners often confuse it with memory access — but it isn’t.

Rule of thumb: No brackets → no memory access

3. Indirect Addressing

Indirect addressing uses a register that contains a memory address.

Step-by-step:

1. EBX holds a memory address

2. The CPU looks at that address

3. The value stored there is loaded into EAX

This is exactly how pointers work at the assembly level.

Important distinction:

ebx → the number inside the register

[ebx] → the data stored at the address contained in EBX

4. Indexed Addressing

Indexed addressing calculates a memory address using a base register plus an offset.

What’s happening:

Start at the address in EBX

Move forward by 4 bytes

Read the value stored there

This addressing mode is commonly used for:

Arrays

Structures

Walking through memory in loops

Mental model:

“Start here, then move forward this many bytes.”

Indexed addressing is the foundation of data structures in assembly.

DATA TRANSFER INSTRUCTIONS: MOV, PUSH, AND POP

With operands and addressing modes understood, data transfer instructions become much clearer.

MOV — Copy Data

MOV copies data from a source to a destination.

Examples:

Important rule: 

❌ You cannot move memory directly to memory and 

✅ One operand must be a register. 

PUSH and POP: Stack Transfers

The stack is a special region of memory managed using the stack pointer (ESP).

What PUSH does:

1. Decreases ESP

2. Stores the value at the new top of the stack

What POP does:

1. Reads the value at the top of the stack

2. Increases ESP

The stack is heavily used for:

• Function calls

• Passing parameters

• Saving registers

Operators That Help with Memory

Assembly provides operators that help calculate and interpret memory addresses.

I. OFFSET

OFFSET gives the address of a variable, not its value.

This loads the memory address of myVar into EAX.

II. PTR

PTR tells the assembler how to treat a memory operand.

This forces the assembler to treat the memory as a WORD.

This matters because:

• Assemblers do not perform strict type checking

• The CPU needs to know how many bytes to read

III. LENGTHOF

LENGTHOF calculates how many elements are in a data structure.

This is commonly used when writing loops.

LOOPS AND ARITHMETIC (PREVIEW)

With data transfer understood, you can now:

• Create loops using JMP and LOOP

• Perform arithmetic with ADD, SUB, MUL, and DIV

• Move through arrays and structures using indexed addressing

All of these depend on correct data movement.

FLAT MEMORY MODEL AND STDCALL (WINDOWS CONTEXT)

When writing 32-bit Windows programs, you’ll often see:

I. Flat Memory Model

One continuous 32-bit address space

No segment juggling

Memory is treated as a single linear block

This simplifies memory access and matches how modern Windows works.

II. STDCALL Calling Convention

STDCALL defines:

How parameters are passed (right to left on the stack)

Who cleans up the stack (the callee)

How functions interact with the Windows API

This consistency is critical for Windows compatibility.

III. Big Picture Summary

Data transfer moves values between registers, memory, and the stack

Operands define what data is used

Addressing modes define how memory is reached

MOV, PUSH, and POP are the core transfer instructions

OFFSET, PTR, and LENGTHOF help manage memory correctly

Flat memory and STDCALL define the Windows execution environment

Once this chapter clicks, you’re no longer guessing...

The real concepts being discussed here are:

1. Direct memory operands (a form of direct addressing)

2. The difference between a value, an address, and the contents at an address

3. How notation (var, [var], hex literals) changes meaning

Direct Memory Operands: Talking to Memory by Name

A direct memory operand means:

“Access the contents of a specific memory location whose address is known at assembly time.”

In plain English:

The assembler knows exactly where this variable lives in memory

The instruction hardcodes that address into the machine code

I. What “direct” really means here

When you write:

You are saying: “Go to the memory location associated with var1, read the byte stored there, and copy it into AL.”

var1 is not the value itself.

var1 is a label that represents a fixed memory address.

II. Declaring a variable: clearing the confusion

This line means three separate things:

1. var1 → a label (a name for a memory location)

2. BYTE → the size of memory being reserved (1 byte)

3. 10h

→ the initial value stored in that byte

→ hexadecimal 10h = decimal 16

So what does var1 contain?

• It contains one byte

• That byte’s value is 16 (decimal)

What it does not mean

• ❌ It does NOT mean “a string”

• ❌ It does NOT mean “hex data is a string”

• ❌ It does NOT mean “10 characters”

Hexadecimal is just a number format, not a data type.

III. Hex ≠ string (important mental reset)

This is where many people get tripped up.

• Hexadecimal → a way to write numbers

• String → a sequence of characters stored as numeric codes (ASCII / Unicode)

Example:

Stores:

That byte does not represent text unless you interpret it as text — and even then, ASCII 16 is a non-printable control character.

So no, a BYTE holding 10h cannot secretly be a string.

IV. Direct memory operand in action

What the CPU actually does:

1. The assembler replaces var1 with its memory address

2. That address is embedded into the instruction

3. At runtime, the CPU:

• goes to that address

• reads 1 byte

•  loads it into AL

V. Why machine code looks like this

We mentioned this:

Breaking it down:

• A0 → opcode (MOV AL, moffs8)

• 00010400 → 32-bit memory address of var1

This is why it’s called direct:

the address is literally baked into the instruction.

VI. Direct memory operands with other instructions

Anywhere a memory operand is allowed, direct memory operands can be used:

These all mean: “Use the contents of the memory location named var1.”

VII. Direct memory + expressions

This is called a direct-offset operand.

Meaning:

1. Take the address of var1

2. Add 5 bytes

3. Access the memory at that computed address

This is commonly used for:

• arrays

• structure fields

• table lookups

VIII. Why brackets matter (this is HUGE)

No brackets → value or address

This means:

“Load the number 10000438h into EAX.”

The CPU does not touch memory.

Brackets → dereference (go to memory)

This means:

“Go to memory address 10000438h and load what’s stored there.”

Golden rule:

Brackets mean “treat this as an address and go there.”

This applies whether the thing inside is:

• a label → [var1]

• a register → [ebx]

• a hex literal → [10000438h]

IX. Can a hex number be a value or an address?

Yes — and this is why context matters.

Hex is just a number.

These are different even though the hex is the same:

Same number.

Completely different meaning.

X. BYTE vs DWORD (size clarity)

• BYTE → 1 byte (0–255)

• DWORD → 4 bytes (32 bits)

The type:

• tells the assembler how much space to reserve

• tells the CPU how many bytes to read/write

It does not decide whether something is a value or an address — brackets do.

XI. Opcode vs Operand (clean mental split)

Opcode → what the CPU should do

(MOV, ADD, SUB)

Operands → what data the operation works on

(registers, memory, immediates)

Example:

✅✅✅✅✅✅✅✅✅✅✅

✅✅✅✅✅✅✅✅✅✅✅

✅✅✅✅✅✅✅✅✅✅✅

✅✅✅✅✅✅✅✅✅✅✅

✅✅✅✅✅✅✅✅✅✅✅

✅✅✅✅✅✅✅✅✅✅✅

✅✅✅✅✅✅✅✅✅✅✅

✅✅✅✅✅✅✅✅✅✅✅

✅✅✅✅✅✅✅✅✅✅✅

Opcode → ADD

Operands → EAX, 3

XII. Big picture takeaway (this is the anchor)

Direct memory operands mean:

• You name a variable

• The assembler knows its exact address

• The instruction directly accesses that memory location

Brackets decide everything:

• No brackets → value

• Brackets → memory dereference

Once this clicks, pointers, arrays, and structures stop feeling mysterious — they’re just address + size + interpretation.

The MOV instruction as a controlled copy operation, governed by operand roles, sizes, and allowed combinations. 

The MOV instruction is used to copy data from one place to another. 

What MOV actually does

MOV copies data.

It does not:

• add

• swap

• compare

• or modify the source

After a MOV:

• the destination changes

• the source stays exactly the same

Think of it like copying text:

You paste the text somewhere else, but the original is untouched.

Destination vs Source (this matters)

Destination operand

• The place where the data ends up

• This operand is modified

Source operand

• The data being copied

• This operand is not modified

Example:

• EAX → destination (changed)

• EBX → source (unchanged)

Operand sizes must match

Both operands must be the same size. Valid:

Invalid: 

The CPU needs to know exactly how many bytes to move.

MOV cannot move memory to memory (and why)

This is one of the most important rules:

❌ MOV cannot copy data directly from one memory location to another.

This is not a syntax limitation — it’s a CPU rule.

Memory-to-memory moves would require:

• two memory reads

• one memory write

• extra internal buffering

x86 keeps things simple and fast by requiring at least one operand to be a register.

How to move data from memory to memory (the correct way)

You use a register as a temporary step.

What’s happening:

1. The value of var1 is loaded into AX

2. The value in AX is stored into var2

Result: var2 now contains the same value as var1

Register → Memory example

Step-by-step:

1. 1024 is loaded into EAX

2. The contents of EAX are copied into memory at var3

Important idea:

• var3 is just a name for a memory address

• The assembler reserves 4 bytes because it is a DWORD

After execution: var3 holds the value 1024

Memory → Register example

What happens:

1. The CPU goes to the memory location named var4

2. Reads 4 bytes

3. Copies them into EAX

After this instruction: EAX = 1024

Immediate values with MOV

You can also move immediate (literal) values into registers or memory.

Rules:

• Immediate → register ✔

• Immediate → memory ✔

• Immediate → immediate ❌ (doesn’t make sense)

Summary: All valid MOV forms

And the one that’s not allowed: 

Why MOV is so important

Almost everything in assembly depends on MOV:

• loading values

• storing results

• passing function parameters

• working with memory

• preparing data for arithmetic

If you understand:

• destination vs source

• size matching

• register involvement

then you understand how data flows through the CPU.

Big picture takeaway

MOV is not “move” — it’s copy.

It copies:

• values

• addresses

• memory contents

But it always follows strict rules so the CPU knows:

• how much data to copy

• where it’s coming from

• where it’s going

Master MOV, and assembly stops feeling chaotic — it becomes deliberate and predictable.

More specifically:

• How AL, AX, and EAX share the same physical storage

• How writing to a smaller part of a register affects (or does not affect) the rest

Overlapping Values: How Partial Register Writes Work

In x86 assembly, many registers overlap.

This means that smaller registers are not separate storage — they are views into a larger register.

The best example is EAX.

I. The EAX register layout (mental model)

A 32-bit register like EAX is divided like this:

• AL → lowest 8 bits

• AH → next 8 bits

• AX → lowest 16 bits (AH + AL)

• EAX → all 32 bits

They all refer to the same physical register.

II. Data declarations (what we’re loading)

• oneByte → 8 bits → 78h

• oneWord → 16 bits → 1234h

• oneDword → 32 bits → 12345678h

Step-by-step: how EAX changes

I. Clear EAX

All 32 bits are zeroed: EAX = 00000000h

II. Move a BYTE into AL 

What happens:

• Only AL (lowest 8 bits) is overwritten

• The upper 24 bits remain unchanged

 EAX = 00000078h 

Key idea: Writing to AL affects only 1 byte.

III. Move a WORD into AX

What happens:

• The lower 16 bits are overwritten

• The upper 16 bits remain unchanged

 EAX = 00001234h 

Notice:

• The previous 78h in AL is gone

• Because AL is part of AX

IV. Move a DWORD into EAX

What happens:

All 32 bits are replaced - EAX = 12345678h

No overlap concerns here — the entire register is rewritten.

V. Zero AX only

What happens:

• Lower 16 bits → set to zero

• Upper 16 bits → unchanged

 EAX = 12340000h 

 This is where people get surprised.

VI. Why this matters (the dangerous part)

Because partial writes do not clear the rest of the register, you can easily end up with garbage in the upper bits if you’re not careful.

Example bug:

Reality: EAX = ??????01h

Unless EAX was cleared earlier, the upper bits contain whatever was there before.

VII. Golden rules for overlapping registers

Rule 1: Smaller writes do not clear larger registers

• mov al, x → changes 8 bits

• mov ax, x → changes 16 bits

• mov eax, x → changes all 32 bits

Rule 2: If you care about the full register, write the full register

Instead of:

Now you know the upper bits are zero.

Rule 3: Overlap works both ways

• Writing to AX overwrites AL

• Writing to AL does not preserve meaningful values in AX

• Everything overlaps downward

VII. Why x86 works this way

This design exists for:

• backward compatibility (8-bit and 16-bit CPUs)

• performance

• flexibility

It’s powerful — but sharp.

VIII. Big picture takeaway

AL, AX, and EAX are not separate registers.

They are different-sized windows into the same storage.

When you move smaller data into a larger register:

• it goes into the lower portion

• the upper bits are untouched

Understanding this prevents:

• subtle bugs

• incorrect comparisons

• broken arithmetic

• mysterious values

Once this clicks, you start controlling the CPU. 

Zero Extension (moving a smaller unsigned value into a larger register)

Zero extension is used when you move a smaller unsigned value (for example, 8-bit or 16-bit) into a larger register (like a 32-bit register), and you want the extra space to be filled with zeros.

This is important because unsigned values do not have a sign. 

So, when we make them bigger, we must not copy or invent a sign bit. 

We simply add zeros to the left.

The basic idea is simple:

1. First, clear the larger register (set it to zero).

2. Then, move the smaller value into the lower part of that register.

3. The upper bits stay zero, which is exactly what we want.

Example setup

Let’s say we have a variable called count:

• count is a 16-bit unsigned integer

• Its value is 1

• In hexadecimal, that value is 0001h

Assembly code example (Zero Extension)

What happens step by step

Step 1: Clear ECX

This sets all 32 bits of the ECX register to zero: ECX = 00000000h 

This step is important because it guarantees that the upper 16 bits are zero before we move anything into ECX.

Step 2: Move the 16-bit value into CX

• • CX is the lower 16 bits of ECX

  • The value of count is 0001h

  • This instruction copies 0001h into the lower 16 bits only

After this instruction:

• Upper 16 bits of ECX: 0000h

• Lower 16 bits of ECX: 0001h 

So, the full 32-bit value of ECX becomes: ECX = 00000001h

We took a 16-bit unsigned value and placed it into a 32-bit register.

The extra 16 bits on the left were filled with zeros, not sign bits. 

That is why this is called zero extension.

Final result (important correction)

• Hex value in ECX: 00000001h

• Decimal value in ECX: 1

We copied the number 1 into ECX and padded it on the left with zeros.

The value stays 1, not 16.

MOVZX and MOVSX Instructions

(Move with Zero Extension / Move with Sign Extension)

When moving smaller values (8-bit or 16-bit) into larger registers (16-bit or 32-bit), we often need to extend the value.

Intel provides two special instructions that do this automatically:

• MOVZX → for unsigned values

• MOVSX → for signed values

These instructions save us from manually clearing registers and make our code shorter, safer, and easier to read.

Instruction Forms

I. MOVZX (Zero Extension)

II. MOVSX (Sign Extension) 

MOVZX: Move with Zero Extension

MOVZX copies a smaller unsigned value into a larger register and fills all the extra bits with zeros.

It does not care about signs.

It treats the value as always positive.

I. Example: Zero extension with MOVZX

Data section

Code section 

What happens step by step

• count is 16 bits and equals 0001h

• ECX is 32 bits

MOVZX:

Copies count into the lower 16 bits of ECX

Fills the upper 16 bits with zeros

Final result: ECX = 00000001h

Decimal value: 1

This is zero extension — the value is extended by adding zeros on the left.

MOVSX: Move with Sign Extension

MOVSX copies a smaller signed value into a larger register and preserves the sign.

• If the value is positive, it fills the upper bits with 0

• If the value is negative, it fills the upper bits with 1

This keeps the number mathematically correct after the move.

I. Example: Negative signed value

Data section and code section

What happens step by step

• signedVal = -16

• Hex value (16-bit): FFF0h

• Sign bit = 1 (negative)

After MOVSX: ECX = FFFFFFF0h

The upper bits are filled with 1s, preserving the negative sign.

Important Question:

Do signed values have to be negative for MOVSX?

No. Absolutely not.

MOVSX works for both positive and negative signed values.

Example: Positive signed value

Data section and Code section

What happens here?

• 42 in hex is 002Ah

• Sign bit = 0 (positive)

After MOVSX: ECX = 0000002Ah 

 The value stays positive, and the upper bits are filled with zeros.

Sign preserved correctly

Key Rule for Sign Extension (Very Important)

When using MOVSX, always look at the most significant bit (sign bit):

• Sign bit = 0 → positive → extend with zeros

• Sign bit = 1 → negative → extend with ones

Why do we need MOVZX if MOVSX exists?

Great question — and this is where many learners get confused.

Short answer: Because MOVSX can break unsigned values.

MOVZX — for unsigned data

• Always fills upper bits with zeros

• Safe for values like counters, sizes, indexes

Example:

MOVSX — for signed data

• Copies the sign bit

• Correct for negative numbers

• Dangerous for unsigned values

Example problem:

That’s why MOVZX exists.🚨 

Final Summary (Simple and Clear)

MOVZX

Used for unsigned values

Upper bits are filled with zeros

Prevents accidental negative values

MOVSX

Used for signed values

Upper bits copy the sign bit

Preserves positive or negative meaning

👉 Always choose based on the data type, not the instruction size.

Movzx Repeated

What is happening here:

MOVZX, which stands for Move with Zero Extension, is an instruction that lets us take a value that is stored in a smaller register or memory location and copy it into a bigger register. 

When we do this, the extra space in the bigger register (the upper bits) is filled with zeros so that the value stays the same. Let’s look at some examples using registers to understand how this works step by step. 

1. Example: Register Operands

In this example, we used the MOVZX instruction to copy smaller pieces of data from one place into bigger registers, making sure that any extra space is filled with zeros. Let’s take it one step at a time:

1. mov bx, 0A69Bh – Here, we put the 16-bit value 0A69Bh into the BX register. Think of BX as a small container that can hold 16 bits (2 bytes).

2. movzx eax, bx – Now, we want to copy that 16-bit value from BX into the larger 32-bit register EAX. Because EAX is bigger, MOVZX fills the extra 16 bits at the top with zeros. After this, EAX contains 0000A69Bh.

3. movzx edx, bl – BL is the lower 8 bits of BX (just the last byte). We copy this into the 32-bit register EDX using MOVZX. The top 24 bits of EDX are filled with zeros, so the final value is 0000009Bh.

4. movzx cx, bl – Finally, we copy that same 8-bit value from BL into the 16-bit register CX. Since CX has space for 16 bits, the upper 8 bits are filled with zeros, giving 009Bh.

2. Example: Memory Operands

In this example, we used MOVZX again, but this time the data comes from memory instead of registers. We have two variables in memory: byte1 (8 bits) and word1 (16 bits). Here’s what happens step by step:

1. movzx eax, word1 – We take the 16-bit value stored in word1 and copy it into the 32-bit register EAX. Since EAX is bigger than word1, MOVZX fills the extra 16 bits at the top with zeros. After this, EAX contains 0000A69Bh.

2. movzx edx, byte1 – Now we take the 8-bit value in byte1 and copy it into the 32-bit register EDX. The top 24 bits are filled with zeros, so EDX becomes 0000009Bh.

3. movzx cx, byte1 – Finally, we copy the same 8-bit value from byte1 into the 16-bit register CX. The upper 8 bits of CX are filled with zeros, giving 009Bh.

The important idea here is that MOVZX always fills the extra bits with zeros when moving smaller values into larger registers. This keeps the value correct and avoids accidentally changing the sign of the number.

MOVSX Repeated

What is happening here?

Here, we are looking at MOVSX, which copies smaller values into larger registers while preserving the sign (positive or negative). We’re using the hexadecimal value 0A69Bh as an example. Here’s what happens step by step:

1. mov bx, 0A69Bh – This puts the 16-bit value 0A69Bh into the BX register. The first digit "A" in hexadecimal means that the highest bit (the sign bit) is 1, so this value is considered negative in signed representation.

2. movsx eax, bx – We copy the 16-bit value in BX into the 32-bit register EAX. Because we are using MOVSX, it keeps the sign the same. The upper 16 bits of EAX are filled with ones (F in hex) to preserve the negative sign. After this, EAX = FFFFA69Bh.

3. movsx edx, bl – Now we take the lower 8 bits of BX (called BL) and copy them into the 32-bit EDX register. MOVSX again preserves the sign. The upper 24 bits of EDX are filled with ones, so EDX = FFFFFF9Bh.

4. movsx cx, bl – Finally, we copy the 8-bit BL into the 16-bit register CX. The upper 8 bits of CX are filled with ones because the sign bit is 1, giving CX = FF9Bh.

Key point: The "A" in 0A69Bh shows that the number is negative in signed form. MOVSX makes sure that when we copy smaller numbers into larger registers, the sign is preserved by filling the extra bits with ones for negative numbers.

The LAHF (Load AH from Flags) and SAHF (Store AH into Flags) instructions are used to move specific CPU flags to and from the AH register. 

These instructions are useful when you want to save or restore the status of certain flags without affecting the rest of the EFLAGS register.

LAHF — Load AH from Flags

I. What it does

• The LAHF instruction takes the low byte of the FLAGS register (specifically the SF, ZF, AF, PF, and CF flags) and copies it into the AH register.

• This allows you to save the state of these flags for later use, such as storing them in memory or comparing them without changing the CPU state.

II. Flags included in LAHF

Note: LAHF does not load all EFLAGS, only these selected flags.

III. Example: Using LAHF

Note: LAHF does not load all EFLAGS, only these selected flags.

Step-by-step explanation:

1. lahf copies the low byte of FLAGS into the AH register.

2. mov [savedFlags], ah stores the value of AH into a memory variable called savedFlags.

3. Later, you can restore these flags using SAHF.

In this example, after executing LAHF, the AH register contains the values of the specified flags, and you can save these values in the saveflags variable for future reference.

SAHF (Store AH into Flags)

The SAHF instruction works in the opposite direction. It copies the value from the AH register into the low byte of the EFLAGS (or RFLAGS) register.

This allows you to restore saved flag values.

Here's an example of how to use SAHF to retrieve saved flag values from a variable:

EFLAGS / RFLAGS Register

The EFLAGS register (called RFLAGS in 64-bit mode) is like a control panel for the CPU.

• It’s 32 bits (4 bytes) in 32-bit mode, and 64 bits (8 bytes) in 64-bit mode.

• It stores status flags that tell the CPU what happened after each instruction.

• It also has control bits that affect how the CPU works.

Some of the important flags you’ll see in EFLAGS/RFLAGS are:

• Carry Flag (CF): Tells if a calculation carried out of the highest bit.

• Zero Flag (ZF): Tells if the result of a calculation was zero.

• Sign Flag (SF): Tells if the result was negative.

• Overflow Flag (OF): Tells if a calculation overflowed the allowed range.

• …and many others that help the CPU track what’s going on.

In 64-bit mode, the RFLAGS register works the same way as EFLAGS, just bigger (64 bits).

XCHG (Exchange) Instruction 

The XCHG instruction in x86 assembly is used to swap the contents of two operands.

Unlike doing a manual swap using a temporary register, XCHG can handle this directly, which makes your code shorter, cleaner, and sometimes faster.

There are three main variants:

1. XCHG reg, reg – exchanges contents between two registers.

2. XCHG reg, mem – exchanges contents between a register and a memory location.

3. XCHG mem, reg – exchanges contents between a memory location and a register.

Let’s break each one down, with examples and practical notes.

1. XCHG reg, reg

What it does: Swaps the contents of two registers.

• No memory access is required—everything stays inside the CPU registers.

• Useful when you need to reorder values quickly, e.g., swapping two counters.

Example:

Result after execution:

• AX = 10

• BX = 5

Key Points:

Fast, because it only involves registers.

Atomic on most processors, which means it can safely be used in some synchronization tasks (like implementing locks).

2. XCHG reg, mem

What it does: Swaps the value of a register with a value in memory.

Now the CPU has to read from and write to RAM, which is slower than register-only operations.

This is very handy when you need to update a variable without using an extra temporary register.

Example:

Result:

BX now contains the previous value of var1.

var1 now contains 20.

Why it matters:

Helps in swapping array elements directly in memory.

Can also be used in simple locking mechanisms, because XCHG is atomic when working with a register and memory.

3. XCHG mem, reg

What it does: Swaps a memory location with a register. This is technically the same as XCHG reg, mem because the CPU treats memory-register swaps identically, but conceptually it’s about memory being the first operand.

Example (swapping two memory locations using a temporary register):

Result:

val1 and val2 are swapped.

AX temporarily holds the value during the swap.

Why it matters:

Direct memory-to-memory swap isn’t supported on x86, so this pattern (using a register as a “bridge”) is essential.

Shows how XCHG can be combined with MOV to manipulate memory efficiently.

Practical Tips & Takeaways

Atomicity: XCHG is inherently atomic when one operand is a memory location. This makes it useful in multithreading scenarios.

Performance: Register-register swaps are fastest; memory involvement slows things down.

Common Uses:

• Swapping variables (obvious!)

• Sorting algorithms (like bubble sort)

• Implementing simple locks or semaphores in low-level concurrent code

Direct-Offset Operands

Direct-offset operands let you access memory at a specific location by starting from a variable’s base address and adding an offset.

They’re useful for arrays or structures, where you want to pick a specific element.

The offset is just a number that tells the CPU how far from the base address to go.

Example concept:

If you have arrayB, then arrayB + 20 is the effective address of the second element (first element is at arrayB + 0).

Adding brackets, like [arrayB + 20], tells the assembler: “I want the value stored at this memory location, not the address itself.”

Tip:

You don’t have to use brackets in MASM, but it’s much clearer if you do.

MASM doesn’t check if your address is in range, so if your array has 20 bytes and you access arrayB + 20, you’ll read memory outside the array. This won’t cause an immediate error but can create a sneaky logic bug.

I. Word and Doubleword Arrays

When accessing word and doubleword arrays, you need to take into account the size of the array elements. 

For example, the following code shows how to access the second element in an array of 16-bit words:

To put it simply, [arrayW + 2] is a way of telling the computer: 

"Start at the beginning of the list called arrayW, skip the first item, and look at the second one."

II. Why do we add 2?

Computers don't see "items" in a list; they see bytes (tiny units of storage).

• In this specific list (arrayW), every single item takes up 2 bytes of space.

• To get to the second item, you have to jump over those first 2 bytes.

The code [arrayW+2] tells the computer to skip the first 2 bytes of the list. Since each item in this list is 2 bytes big, this jump moves you exactly to the start of the second item.

In the same way, if the items are "doublewords" (4 bytes big), you would add 4 to reach the second item.

The code [arrayD+4] tells the computer to skip the first 4 bytes to reach the second item in the list. This is because each item in this list is 4 bytes wide.

You must be careful: the computer will not stop you if you jump too far. 

If you use a number that is too large, you might accidentally look at memory that doesn't belong to your program, which can cause errors.

III. Growing Your Data (MOVZX vs MOVSX)

When you move a small piece of data into a bigger box, you have to decide what to do with the empty space.

MOVZX (Zero Extension): This is the "clean" one. It just fills the empty space with zeros. It’s perfect for positive numbers.

MOVSX (Sign Extension): This is the "smart" one. It looks at the very first bit of your number. If it’s a negative number, it fills the empty space with 1s to keep the number negative. If it's positive, it uses 0s.

IV. The Swap (XCHG)

Usually, to swap two things, you need a third hand. XCHG is like a magic trick—it swaps the values in two places at the exact same time without needing a middleman.

V. Jumping Through Arrays

Computers don't see "lists"; they see a long line of bytes.

To get to the next Byte, you move 1 step.

To get to the next Word, you move 2 steps.

To get to the next Doubleword, you move 4 steps.

VI. The Exit

ExitProcess is just the "Power Off" button. It tells Windows, "I'm done, you can take your memory back now."

Here, we compiled the program and started debugging it in x64dbg instead of visual studio community, coz it doesn't have the registers option:

You can see the registers, flag registers, memory dumps, stack etc.

Each flag is assigned a value of 0 (clear) or 1 (set). 

Here’s an example:

Yes, it’s completely normal for a disassembled EXE to have more lines of code than what you actually wrote. 

That’s because the compiler adds extra code to handle things like library functions, operating system calls, and other behind-the-scenes tasks.

In the disassembly, you can see the compiler has added instructions to set up the stack, call main(), and exit the program. 

It also includes code to handle errors, like division by zero or invalid memory access.

On top of that, any libraries your program uses—like the C standard library—bring in their own code, which gets included in the EXE. 

And sometimes, other programs, like debugging tools or malware, can add code too.

If you want to dig deeper into what’s in the disassembled EXE, a debugger lets you step through the code and inspect registers and memory. You can also use a disassembler to get a detailed view of the assembly instructions.

x64dbg – Human-Friendly Window & Operand Guide

Debugging with x64dbg can feel overwhelming at first because there are a lot of windows and registers to keep track of. 

Let’s break it down step by step, in plain English, explaining what each window shows, why it matters, and how you can use it.

1. Call Stack Window

What it is:

Think of the call stack as a breadcrumb trail of function calls that led to where the program is now.

How it works:

Functions are listed in reverse order. The top entry is the most recent function that was called.

You can see which function called it, and which function called that one, all the way back to the start of the program.

Why it matters:

Helps you figure out how you got here in the program.

Useful for tracking nested function calls and debugging crashes (like “segmentation faults”).

How to open:

View > Call Stack

2. Memory Map Window

What it is:

The Memory Map shows a bird’s-eye view of the program’s memory.

What you see:

Loaded modules (DLLs, EXEs)

Data segments (variables)

Stack and heap areas

Why it matters:

Helps you understand where different pieces of the program are in memory.

Essential when working with pointers, arrays, or investigating crashes due to invalid memory access.

How to open:

View > Memory Map

3. Command Window

What it is:

This is a text-based control panel where you type debugger commands directly.

Things you can do:

Start and stop the debugger

Set and remove breakpoints

Step through code one instruction at a time

Inspect or change values in registers or memory

Why it matters:

Gives you full control of the debugger

Great for advanced users who want precision over what the debugger is doing

4. Registers Window

What it is:

Registers are like tiny, ultra-fast memory slots inside the CPU. They store:

Current instruction pointer

Calculation results

Addresses for memory operations

Why it matters:

By watching registers, you can see exactly what the CPU is thinking.

Essential for understanding how the program is executing at the machine level.

5. Disassembly Window

What it is:

Shows machine code translated into assembly instructions.

Why it matters:

Lets you see what the CPU is actually doing

Critical for reversing programs or debugging tricky bugs

6. Variables Window

What it is:

Displays program variables and their current values.

Why it matters:

Lets you track how data changes over time

Useful for debugging logic errors or tracking unexpected program behavior

7. Threads Window

What it is:

Shows all threads (independent paths of execution) in a program.

Why it matters:

Lets you pause, resume, or switch between threads

Essential for debugging multithreaded programs

8. Breakpoints Window

What it is:

Lists all breakpoints, which are markers telling the debugger to pause execution at specific points.

Why it matters:

Lets you inspect program state at critical moments

Makes it easier to debug step by step instead of running blindly

Assembly Operand Basics (Human-Friendly Version)

Assembly instructions operate on operands, which are the “things” being manipulated. There are three basic types:

1. Register operands – stored in CPU registers (e.g., EAX, ECX)

2. Memory operands – stored in memory locations (e.g., [var1])

3. Immediate operands – fixed values built into the instruction itself (e.g., 42)

MOV Instruction Tips

1. Destination and Source:

The first operand = destination (where the data goes)

The second operand = source (where the data comes from)

2. Limitations:

Destination cannot be a segment register or the instruction pointer (EIP)

You can’t move data directly into special registers like EIP

Operand Notation

reg/mem32 → can be a 32-bit register or a 32-bit memory location

imm16 → a 16-bit immediate value (a number hard-coded into the instruction)

I. INC (Increment)

The INC instruction increments the value of a register or memory operand by 1. Here's the syntax:

For example, if you have a data segment with a variable myWord initialized to 1000h, you can use INC like this:

II. DEC (Decrement)

The DEC instruction decrements the value of a register or memory operand by 1. Its syntax is similar to INC:

For instance, you can use DEC to decrement the value stored in the bx register:

III. Flags Affected by INC and DEC

When you use the INC (increment) or DEC (decrement) instructions, they don’t just change a number—they also play with the CPU’s status flags. Here’s what happens:

Overflow Flag (OF): Changes if the operation causes a signed overflow.

Sign Flag (SF): Reflects the new sign (positive or negative) of the result.

Zero Flag (ZF): Turns on if the result ends up being zero.

Auxiliary Carry Flag (AF): Updates for certain lower-nibble carries—useful for BCD arithmetic.

Parity Flag (PF): Indicates whether the number of set bits in the result is even or odd.

Fun twist: The Carry Flag (CF) doesn’t budge! That’s a little unexpected since we usually associate arithmetic operations with the carry. So, INC and DEC can change a lot of flags, but CF stays put.

💡 Pro tip: In assembly, tiny details matter. One increment or decrement can subtly shift the CPU’s state. Knowing exactly which flags are affected helps you predict behavior and write programs that behave like clockwork.

ADD INSTRUCTION

The ADD instruction is used to add a source operand to a destination operand of the same size. Here's the syntax:

or

Assembler doesn't care about capital letters!

• The source operand remains unchanged.

• The sum of the operands is stored in the destination operand.

For example, let's add two 32-bit integers:

The instruction affects various CPU flags, including Carry, Zero, Sign, Overflow, Auxiliary Carry, and Parity.

How these flags change depends on the result placed in the destination operand.

SUB INSTRUCTION

The SUB instruction subtracts a source operand from a destination operand. The syntax is the same as for ADD:

Like ADD, the source operand remains unchanged.

The result of the subtraction is stored in the destination operand.

For example, let's subtract two 32-bit integers:

Again, this instruction affects CPU flags such as Carry, Zero, Sign, Overflow, Auxiliary Carry, and Parity based on the value stored in the destination operand.

The SUB instruction subtracts var2 from var1. So, in this case:

• • var1 is the source operand, and it contains the value 30000h.

  • var2 is the destination operand, and it contains the value 10000h.

The SUB instruction subtracts var2 from var1, resulting in EAX being set to 20000h. Therefore, var2 is subtracted from var1.

NEG INSTRUCTION

The NEG (negate) instruction reverses the sign of a number by converting it to its two's complement. 

It can be applied to registers or memory. Here's the syntax:

To find the two's complement, reverse all the bits in the destination operand and add 1.

For example, to negate the value in EAX:

As with ADD and SUB, the NEG instruction also affects CPU flags based on the result.

IMPLEMENTING THE ARITHMETIC EXPRESSIONS

With the ADD, SUB, and NEG instructions, you can implement arithmetic expressions in assembly language. 

You can break down an expression into individual operations and combine them.

For instance, if you want to calculate Rval = -Xval + (Yval - Zval), you can: 

NEGATING A VARIABLE WITHOUT REGISTERS IN ASM

Good news: you don’t need a separate register just to negate a variable. You can do it directly!

In my earlier example, I used extra registers to make the steps super clear—but in real-world coding, you can streamline things for efficiency.

Here’s a leaner version: it negates Xval and calculates Rval without using any extra register:

💡 Tip: Using fewer registers keeps your code clean and can make it run faster. But sometimes, extra registers help with readability—so pick what works best for your situation.

SIGNED NUMBERS

Signed numbers let us represent both positive and negative values in binary. They do this by reserving one bit for the sign and using the rest to show the number’s magnitude (absolute value). The most common system for this is Two’s Complement.

Here’s the magic behind it:

Sign Bit: The leftmost bit (most significant bit) decides the sign.

0 → positive

1 → negative

Magnitude Bits: The remaining bits show the number’s size.

Negating a number in Two’s Complement is simple:

1. Flip all the bits (turn 0s → 1s and 1s → 0s).

2. Add 1 to the result.

Examples:

0010 → +2 (positive, because the sign bit is 0)

1010 → -2 (negative, sign bit is 1)

Step 1: Invert all bits → 0101

Step 2: Add 1 → 0101 + 1 = 0110 → -2

💡 Tip: Think of Two’s Complement as a clever trick: it lets addition and subtraction work seamlessly, even with negative numbers, without needing separate rules.

UNSIGNED NUMBERS

Unsigned numbers are the “always-positive” kind. They only represent zero or positive values, because they use all their bits just to show the magnitude—no sign bit needed.

Examples:

0010 → 2

There’s no way to represent negative numbers here, so things like negation just don’t exist.

Quick takeaway:

• Signed numbers: have a sign bit, so they can go positive or negative.

• Unsigned numbers: all positive, max value bigger for the same number of bits.

💡 Tip: Pick signed or unsigned based on what your program actually needs—don’t waste bits on a negative that will never show up!

SIGNED VS UNSIGNED NUMBERS: AVOIDING CONFUSION

Sometimes people see a binary number starting with 1 and immediately think, “Ah! It must be a negative signed number!” 🤔

This is a classic mix-up if you don’t know whether the number is signed or unsigned.

Here’s how to prevent that confusion:

1. Label it clearly

Use descriptive variable names: signedValue vs unsignedValue.

Add comments in your code:

 2. Stick to standard conventions

Signed numbers → Two’s Complement

Unsigned numbers → plain binary

Knowing the convention tells you how to interpret the leading bit.

3. Use the correct data types

If your language supports it, pick int (signed) or uint (unsigned).

Be consistent: don’t mix signed and unsigned in the same calculation.

4. Document & educate

Always note your assumptions about signed vs unsigned numbers.

Teach your team: the leading 1 doesn’t automatically mean negative—it depends on the representation.

5. Test and validate

Run small examples to check your assumptions.

Example: 0010 → 2 unsigned, +2 signed; 1010 → 10 unsigned, -6 signed.

6. Keep operations separate

Don’t mix signed and unsigned arithmetic.

Separate them in code to avoid mistakes.

💡 Memory Trick:

Think of signed numbers as “the leading bit is a mood indicator”:

0 → happy/positive

1 → grumpy/negative

Unsigned numbers? They’re always happy—no grumpiness allowed! 

When your program does arithmetic, you often want to know:

Is the result positive, negative, or zero?

Does it fit within the range of the variable storing it?

This is where CPU status flags come in—they’re tiny indicators that give you the answers instantly.

These flags are super important:

They help detect errors.

They let your program make decisions based on the result (like branching or looping).

Here's a straightforward overview of the main status flags.

First, remember this, MSB is the leftmost bit: 

CARRY FLAG

Set when the result of an unsigned arithmetic operation is too large to fit into the destination operand.

In this example, when you add 1111 and 1101, you have a carry-out from the MSB (leftmost bit), resulting in a final carry-out value of 11000. The Carry flag would be set to indicate this carry-out condition.

For subtraction, there's typically no carry-out from the MSB, as subtraction involves taking away one value from another:

In this subtraction, there's no carry-out from the LSB, so the Carry flag would not be set. The carry-out occurs from the least significant bit (LSB), and propagates towards the most significant bit (MSB) during addition, not from the MSB.

This flag indicates unsigned integer overflow. For instance, if an operation has an 8-bit destination operand, but the result exceeds 255 in binary (11111111), the Carry flag is set.

Another example, subtracting 2 from 1 sets the carry flag.

The Carry Flag (CF) is like the CPU’s little “overflow detector” for the most significant bit (MSB). It tells you whether a number got too big to fit in the bits you have.

CF = 1 → Carry happened

This means the sum overflowed the MSB during an addition.

In plain English: the number got too big to fit, so a carry was “pushed out” of the leftmost bit.

CF = 0 → No carry

Nothing overflowed; the result fits perfectly in the allocated bits.

💡 Think of it like this:

CF = 1 → “Oops! Too big!” 😬

CF = 0 → “All good, fits just right!” 😎

In short, CF helps your program know when numbers spill over the size limit of their binary container.

AUXILIARY CARRY FLAG

This flag is set when a 1 bit carries out of position 3 in the least significant byte of the destination operand.

Suppose we want to add 1 to the BCD value 0Fh:

Here's the binary representation and the arithmetic:

1. Binary Representation of 0Fh: 00001111

2. Binary Representation of 1: 00000001

Now, let's add them together, keeping track of the AC flag:

The Auxiliary Carry (AC) flag is a bit like the “bit 3 whisperer” of the CPU—it tells you if a carry happened from bit 3 to bit 4 (counting from the right, starting at bit 0). 

This is especially handy in BCD (Binary-Coded Decimal) arithmetic, where numbers are handled in a decimal-like way using binary.

Example:

• Adding 0Fh + 1 → the result is 10h.

• Notice that a carry goes from bit 3 to bit 4.

• That’s exactly what the AC flag tracks:

1. AC = 1 → Carry from bit 3 to bit 4 occurred

2. AC = 0 → No carry from bit 3 to bit 4

💡 Think of it like this:

Bit 3 is having a party. If someone “overflows” into bit 4, AC says, 

“Hey, bit 4 got some action!” 🎉

If not, AC stays 0, calm and quiet.

In short, AC is a tiny but important helper for operations where carries between the lower nibbles matter, like in BCD arithmetic.

PARITY FLAG (PF)

The Parity Flag (PF) is the CPU’s way of counting 1s in the least significant byte (the rightmost 8 bits) of a result after an arithmetic or logical operation.

PF = 1 → Even parity

The byte has an even number of 1s.

PF = 0 → Odd parity

The byte has an odd number of 1s.

💡 Think of it like this:

• PF is like a little “even-odd checker” for your bits.

• After each operation, it asks: “Do we have an even number of 1s?” ✅

• If yes → PF = 1 (party’s even!)

• If no → PF = 0 (party’s odd!)

It’s mostly used for error checking and low-level debugging, but knowing it can also help you understand subtle CPU behaviors.

💡 Example 1: ADD Instruction

After the ADD instruction, AL contains the binary value 10001110. 

In this binary representation, there are four 0 bits and four 1 bits.

Since there is an even number of 1 bits (four), the Parity flag (PF) is set to 1. 

This means that PF indicates that the result has an even parity.

💡 Example 2: SUB Instruction

Since there is an odd number of 1 bits (one), the Parity flag (PF) is set to 0. (odd parity)

Parity Flag (PF) – Quick Example

Think of PF as the CPU’s “even-odd bit detector.”

• After ADD, AL = 1111 (four 1s → even) → PF = 1 ✅

• After SUB, AL = 0001 (one 1 → odd) → PF = 0 ❌

In short: PF tells you whether the number of 1 bits in the result is even or odd.

It’s handy for error detection or any situation where parity matters.

OVERFLOW FLAG

I. Signed Numbers and Overflow

An overflow is set when the result of a signed arithmetic operation is too large or too small to fit into the destination operand.

Signed Numbers

A signed number is typically an 8-bit value (it can also be 16-bit) that is evenly divided between positive and negative numbers.

The Most Significant Bit (MSB) determines the sign:

MSB = 0 → Positive number

MSB = 1 → Negative number

For example, the binary number 1011 0011 has MSB = 1, so it is negative.

Taking its two’s complement gives 0100 1101, which is 4D in hexadecimal and represents −77 in decimal.

II. Range of Signed Numbers

For an 8-bit signed number:

The range is −128 to +127 (hexadecimal 80 to 7F).

This includes:

128 positive values (0 to +127)

128 negative values (−1 to −128)

III. Overflow Detection

Overflow occurs when the result of an arithmetic operation exceeds the valid signed number range.

If a positive result produces MSB = 1, a positive overflow has occurred.

If a negative result produces MSB = 0, a negative overflow has occurred.

IV. Overflow Detection Mechanism

To detect overflow, the processor performs an XOR operation on the carry flags C6 and C7 during arithmetic operations.

C0 is the carry from bit 0 to bit 1, C1 from bit 1 to bit 2, and so on.

If the XOR of C6 and C7 equals 1, it indicates that the result has exceeded the limits of signed numbers and an overflow has occurred.

The image represents the carry flags from bit 0 to bit 7 that are generated during an arithmetic operation.

The Overflow flag (OF) is set when the result of a signed arithmetic operation is too large or too small to fit into the destination operand. In the case of 8-bit signed numbers, overflow occurs when the result is:

Greater than +127, or

Less than −128

V. How Overflow Is Detected

To detect overflow, the processor performs an XOR operation on the carry flags C6 and C7:

C6 is the carry into the sign bit (bit 7)

C7 is the carry out of the sign bit

If the result of C6 XOR C7 = 1, then an overflow has occurred, and the Overflow flag is set.

VII. Example

Consider adding two 8-bit signed numbers: 127 + 1

The mathematical result is 128

However, 128 is outside the valid range of an 8-bit signed number

As a result, overflow occurs, and the Overflow flag is set.

The table shows how the carry flags (C6 and C7) and the Overflow flag are affected during this addition. Since the XOR of C6 and C7 equals 1, the processor correctly detects an overflow condition.

VIII. Why the Overflow Flag Is Useful

The Overflow flag helps detect errors in signed arithmetic operations. 

For example, if a program expects the result of an operation to stay within a specific signed range, it can check the Overflow flag:

OF = 0 → Result is valid

OF = 1 → Overflow occurred, and corrective action may be needed

IX. Using the Overflow Flag in Assembly Language

Here is an example of how the Overflow flag can be used in assembly language:

X. Using the Overflow Flag in Assembly Language

The assembly code shown is a simple example of how the Overflow flag (OF) can be used to detect overflow during an addition operation. Here’s how it works:

1. The instruction

• add al, 1

• adds the value 1 to the AL register.

2. After the addition, the processor updates the status flags. The instruction jno no_overflow (Jump if No Overflow) transfers control to the no_overflow label if the Overflow flag is not set.

3. If the Overflow flag is set, execution continues to the overflow label, where the program can handle the error or take corrective action.

XI. Why Overflow Occurs

The Overflow flag is set when the result of a signed arithmetic operation is too large (or too small) to fit into the destination operand.

In this example, the destination operand is the AL register, which is an 8-bit signed register.

The valid range for an 8-bit signed value is −128 to +127.

If the result of the addition exceeds +127 or goes below −128, an overflow occurs, and the Overflow flag is set.

XII. Key Takeaway

The Overflow Flag (OF) is used to detect overflow in signed arithmetic operations. 

It plays a crucial role in ensuring correct results when working with signed data types.

The processor detects overflow by performing an XOR operation on carry flags C6 and C7. 

If the result of this XOR operation is 1, the Overflow flag is set, indicating that the signed result is invalid

ZERO FLAG

Set when the result of an arithmetic operation is zero. 

For example, subtracting two equal values will set the Zero flag.

SIGN FLAG

The Sign flag (SF) is set when the result of an arithmetic operation is negative.

It directly reflects the value of the Most Significant Bit (MSB) of the destination operand.

In simple terms, the Sign flag copies the MSB of the result:

• MSB = 1 → SF = 1, indicating a negative result

• MSB = 0 → SF = 0, indicating a positive result

So, the Sign flag gives a quick way to determine whether the result of an operation is positive or negative.

I. Control of Status Flags

Status flags, including the Sign flag, are controlled automatically by the Arithmetic Logic Unit (ALU).

This means:24861

The user cannot directly set or clear these flags.

Flags are updated automatically based on the result of arithmetic or logical operations.

This behavior ensures that flags always accurately represent the outcome of the last operation.

II. Using Status Flags to Detect Errors

Status flags are commonly used to check for errors or special conditions after arithmetic operations.

Some important examples include:

Overflow Flag (OF):

If OF is set after an addition, it means the result is too large or too small to fit into the destination operand (signed overflow).

Zero Flag (ZF):

If ZF is set, the result of the operation is zero. This is useful for comparisons and decision-making in programs.

III. Role of the Sign Flag in Error Detection

The Sign flag can also help detect unexpected results. For example:

If two positive numbers are added together, the result should also be positive.

If the Sign flag is set after such an operation, it indicates that something has gone wrong (such as overflow).

This makes SF useful not just for identifying negative values, but also for validating arithmetic results.

IV. Determining the Sign of a Result

The Sign flag can be directly used to determine the sign of a number:

SF = 1 → Result is negative

SF = 0 → Result is positive

This is especially useful in conditional branching and decision-making instructions.

V. Effect of Subtraction on the Sign Flag

The provided code demonstrates how the Sign flag is affected by a subtraction operation.

First, a value is moved into a register.

Then, a larger value is subtracted from it.

Since the subtracted value is greater than the original value, the result becomes negative.

As a result, the Sign flag is set to 1, indicating a negative outcome.

In the second example, subtraction is performed on an 8-bit register. The result of the subtraction is −1, which is represented as FFh in hexadecimal (two’s complement form).

Because the MSB of this result is 1, the Sign flag is set.

VI. Final Note

The Sign flag is a powerful and simple tool for:

Identifying negative results

Validating arithmetic operations

Supporting decision-making in programs

By understanding how the Sign flag works alongside other status flags, you gain a much clearer picture of how the CPU processes arithmetic operations and handles errors.

CONTROL FLAGS

Control flags are special flags that control how the CPU operates. In the 8086 microprocessor, there are three control flags:

I. Trap Flag (TF)

When TF = 1, the CPU enters single-step mode.

In this mode, the CPU executes one instruction at a time and then pauses.

This is especially useful for debugging, as it allows programmers to closely observe how each instruction affects registers and flags.

II. Interrupt Flag (IF)

When IF = 1, the CPU allows interrupts.

Interrupts are signals from external devices (such as keyboard, timer, or I/O devices) that require the CPU’s attention.

When an interrupt occurs, the CPU:

1. Temporarily stops the current program

2. Executes the interrupt service routine

3. Returns to the original program after handling the interrupt

III. Direction Flag (DF)

The Direction flag controls the direction of string operations.

When DF = 0, the CPU increments the string pointer after each operation.

When DF = 1, the CPU decrements the string pointer after each operation.

(Image showing TF, IF, and DF in the 8086 flag register)

By default, these flags are cleared (set to 0), which means:

The CPU is not in single-step mode

Interrupts are disabled

String operations move in the forward direction

IV. Uses of Control Flags

Debugging

• The TF flag can be used to execute a program one instruction at a time.

• This makes it easier to trace program flow and identify errors.

• For example, TF can help observe how string instructions behave when the DF flag changes.

Disabling or Enabling Interrupts

• The IF flag allows programmers to disable interrupts when needed.

• This is useful during debugging or while executing critical code sections where interruptions are undesirable.

Controlling String Operations

• The DF flag determines whether string operations move forward or backward in memory.

• For example, setting DF = 1 can be useful when reversing a string.

V. Summary

• • TF → Controls single-step execution (debugging)

  • IF → Enables or disables interrupts

  • DF → Controls the direction of string operations

Control flags play a crucial role in managing CPU behavior. Understanding how they work helps in debugging programs, handling interrupts efficiently, and performing advanced string operations.

The image shows myByte variable, an offset, and the data segment.

The data segment is a section of memory that stores program data eg variables, constants, strings.

The offset is the distance from the beginning of the data segment to the variable myByte.

I. Data Segment, Offset, and Memory Addressing

If the data segment starts at memory address 1000h and the offset of a variable myByte is 200h, then the variable will be stored at:

1000h + 200h = 1200h

So, myByte is located at memory address 1200h.

II. What Is an Offset?

The offset is the distance of a variable from the start of its segment.

The processor uses this offset to locate variables in memory.

When the CPU needs to access myByte, it:

1. Takes the starting address of the data segment

2. Adds the offset of myByte

3. Uses the result as the memory address

The operating system keeps track of:

• The starting address of each program’s data segment

• The size of that data segment

This helps protect one program’s data from being accessed by another program.

IV. Correct Assembly Example (8086-style)

Here is a clean and correct example showing how to access myByte:

V. How This Code Works (Step-by-Step)

mov ax, data_segment

Loads the starting address of the data segment into the AX register.

add ax, offset myByte

Adds the offset of myByte to AX, giving the exact memory address of the variable.

mov al, [ax]

Loads the value stored at that memory address into AL.

The [ax] notation means “use the memory location whose address is stored in AX”.

This is called dereferencing the register.

After execution, AL contains the value of myByte.

Is the Statement About Offset Correct?

Yes — it is correct. ✅

The offset is added to the data segment’s starting address to get the memory address of a variable. This is exactly how the 8086 microprocessor accesses data in memory.

VI. Key Points About Offsets

The offset is a 16-bit value

It allows access to up to 64 KB of memory

This matches the maximum size of a data segment in the 8086

VII. Instructions That Use Offsets

mov — moves data between registers and memory

lea — loads the effective address (offset) of a variable into a register

Example:

VIII. Final Summary

A variable’s memory address = data segment address + offset

The offset tells the CPU where the variable is located inside the segment

[ax] means “read the value from the memory address stored in AX”

Understanding offsets is essential for working with segments, pointers, and memory in assembly language

HOW OFFSETS WORK IN ASSEMBLY

The assembly statement: pArray DWORD bigArray, defines a doubleword (DWORD) variable named pArray and initializes it with the address of bigArray.

In simple terms, pArray acts as a pointer that points to the first element of the bigArray.

The array bigArray contains 500 doubleword (DWORD) elements, so pArray holds the starting address of this block of memory.

I. Using the OFFSET Operator

The OFFSET operator is commonly used to obtain the offset address of a variable in memory.

When accessing a variable, the processor adds this offset to the starting address of the data segment to calculate the variable’s actual memory address.

In other words:

Memory Address = Data Segment Base + OFFSET of the Variable

II. Accessing a Variable Using OFFSET

To access a variable like bVal in memory, you first load its offset and then read the value from that address.

When the code executes:

• The OFFSET operator provides the location of bVal within the data segment.

• The processor uses this offset, along with the data segment’s base address, to locate bVal in memory.

• The value stored at that memory location can then be accessed or moved into a register.

III. Dereferencing and the ESI Register

Dereferencing means accessing the data stored at a memory address.

In this case, the address is stored in the ESI register, and the CPU uses that address to read the actual data from memory.

(If this feels confusing, revisiting pointer book in my C Github repo can really help.)

IV. Effect of the MOV Instruction with OFFSET

After the code executes, the ESI register contains the offset of the variable specified in the MOV instruction.

For example:

After the first MOV instruction, ESI contains the offset of the variable bVal.

This offset is 00404000h, which is the memory location where bVal is stored.

After the second MOV instruction, ESI contains the offset of the variable wVal.

This offset is 00404001h, which is the memory location where wVal is stored.

The same pattern continues for subsequent variables:

each MOV instruction loads the offset of the specified variable into ESI.

Once the offset is in ESI, the processor can dereference it (for example, using [ESI]) to access the actual data stored at that address.

V. Why the OFFSET Operator Is Important

The OFFSET operator is a powerful and commonly used tool in assembly language. It is especially useful for:

Accessing variables in memory

Initializing pointer registers like ESI

Working with arrays, structures, and buffers

In short, OFFSET gives you the address of a variable, and dereferencing that address lets you access the value stored there.

VI. Accessing an Array Element Using OFFSET and ESI

The first line of code in the data segment declares an array named myArray that contains five 16-bit (WORD) values.

In the code segment, the next instruction moves the offset of myArray plus 4 into the ESI register.

The OFFSET operator returns the offset of a variable or label, which is the distance from the beginning of the data segment to that variable or label.

In this case, since myArray is the first variable in the data segment, its offset is 0000h.

Each element in myArray is a WORD (2 bytes):

• First element → offset 0000h

• Second element → offset 0002h

• Third element → offset 0004h

By adding 4 to the offset of myArray, we obtain the offset of the third integer in the array.

VII. Using ESI as a Pointer

The ESI register is a general-purpose register that can store addresses.

By loading the offset of the third element of myArray into ESI, we are effectively creating a pointer to the third integer in the array.

Once ESI holds this address, it can be used to access the value stored at that location.

For example, the following instruction loads the value of the third integer in myArray into the AL register:

VIII. Calculating offsets

For arrays… 

BYTE Arrays:

If you are working with a BYTE array, where each element is 1 byte in size, you can access the next element by adding +1 to the current element's address.

WORD Arrays:

For WORD arrays, where each element is 2 bytes (16 bits) in size, you should add +2 to move to the next element's address.

DWORD Arrays:

DWORD arrays have elements that are 4 bytes (32 bits) in size. To access the next element, add +4 to the current element's address.

QWORD Arrays:

If you are dealing with QWORD arrays, where each element is 8 bytes (64 bits) in size, you should add +8 to move to the address of the next element.

The ALIGN directive is used to place a variable or label on a specific memory boundary, such as a byte, word, doubleword, or paragraph boundary.

Syntax: ALIGN bound 

 Where bound can be 1, 2, 4, or 16.

For example:

ALIGN 1 → byte boundary

ALIGN 2 → word boundary

ALIGN 4 → doubleword boundary

ALIGN 16 → paragraph boundary

Using ALIGN 4 ensures that the next variable starts at a memory address that is a multiple of 4.

I. Why ALIGN Is Important

Proper alignment can improve performance, especially for certain instructions and hardware units.

For example, the FPU (Floating Point Unit) works more efficiently when data is aligned on a doubleword boundary.

II. PTR Operator and Data Types

The PTR operator is used when moving data between memory and registers to explicitly tell the assembler how much data should be accessed.

Common data types used with PTR include:

• BYTE, SBYTE

• WORD, SWORD

• DWORD, SDWORD

• FWORD, QWORD, TBYTE

The PTR operator ensures that the processor interprets the data with the correct size, especially when the variable’s declared type does not match the destination register size.

III. Moving Smaller Data into Larger Registers

Sometimes, you may want to move smaller memory values into a larger register. This is where the PTR operator becomes very useful.

Example: 

What’s Happening Here?

• wordList contains two WORD values

• DWORD PTR tells the assembler to treat the first two WORDs (4 bytes) as a single doubleword

• These 4 bytes are loaded into EAX, combining them into one 32-bit value

IV. ALIGN vs PTR — Not the Same Thing

Even though they’re often mentioned together, ALIGN and PTR serve completely different purposes:

Example of ALIGN Directive:

Here:

• ALIGN 4 ensures myDouble starts at an address divisible by 4

• This improves access efficiency and guarantees proper alignment

V. Final Takeaway

ALIGN decides where data lives in memory

PTR decides how big the data is when you access it

They solve different problems but are both essential for clean, efficient assembly code

BYTE PTR OPERATOR

Think of BYTE PTR as a way to tell the computer, "I know this variable is big, but I only want to look at one byte of it right now."

By default, if you have a large variable (like a 4-byte Doubleword), the assembler expects you to move all 4 bytes at once. 

Using the PTR operator lets you override that. It’s like using a magnifying glass to pick out a specific "chunk" of data rather than grabbing the whole box. 

You'll see this a lot when moving data between memory and registers—it's basically a size-check to make sure the data fits perfectly into the register you're using.

Here is how you'd use BYTE PTR to pluck a single byte out of a larger myDouble variable:

myDouble is a doubleword(4 bytes), so the first byte is 78h.

This code will move the value of the least significant byte of the variable myDouble into the register BL.

Memory Layout of the myDouble Variable. The following image shows the memory layout of the myDouble variable:

The least significant byte of the variable myDouble is at offset 0000h. The most significant byte of the variable myDouble is at offset 0003h.

I. Moving Smaller Values into Larger Destinations

We can use the BYTE PTR operator to move smaller values into larger destination operands. 

For example, the following code moves two words from memory to the register EAX:

II. Grabbing Data with PTR

This code will move the two words from the wordList array into the lower half and upper half of the register EAX, respectively.

Think of PTR as a size filter.

If you have a big 32-bit variable (a DWORD), the computer usually wants to grab the whole thing. PTR lets you change the rules:

DWORD PTR: You’re saying, "Give me the whole 4-byte chunk." 

This fills the entire EAX register.

BYTE PTR: You’re saying, "Just give me the very first byte (the 'LSB')." 

This fits perfectly into the tiny AL register.

III. ALIGN vs. PTR: What’s the difference?

They aren't even doing the same job.

1. ALIGN is for Organization: Imagine you’re parking cars. ALIGN makes sure every car starts exactly at a line so they’re easy to find and the computer can "drive" to them faster. It lives in your data section.

2. PTR is for Execution: This is used inside your code (the instructions). It tells the computer exactly how much data to "pick up" right now—whether it's a tiny 1-byte crumb or the whole 4-byte cookie.

TLDR: ALIGN organizes the shelf; PTR decides how much you’re taking off the shelf.

The TYPE operator returns the size, in bytes, of a single element of a variable.

Think of the TYPE operator as a quick way to ask the computer, "How much space does one single item in this list take up?"

Instead of you having to remember if a variable is a Byte or a DWORD, you just use TYPE. It returns a simple number representing the byte count:

Byte: Returns 1

Word: Returns 2

Doubleword (DWORD): Returns 4

Quadword (QWORD): Returns 8

I. Why use it?

It’s much safer than hard-coding numbers. If you ever change your array from WORD to DWORD, using TYPE means your code updates itself automatically without you having to hunt down every "+2" and change it to a "+4."

II. The Rest of the "Size" Family:

LENGTHOF: Counts how many items are in the array.

SIZEOF: Multiplies LENGTHOF by TYPE to give you the total bytes the whole array uses.

LABEL: Gives a name to a memory location without actually taking up any space itself.

Think of LENGTHOF as a simple counter that tells you how many "items" are in a list, rather than the total number of bytes.

It’s smart with DUP: If you tell the computer to repeat an item 50 times using 50 DUP(0), LENGTHOF knows there are 50 items there.

The "First Line" Catch: This is the part that trips people up. If you start an array on one line and continue it on the next line (without using a comma or specific formatting), LENGTHOF only counts what it sees on that very first line. It’s like it stops reading the list as soon as it hits the end of the row.

III. The Cheat Sheet

If you have myArray WORD 10, 20, 30:

TYPE is 2 (because it's a Word).

LENGTHOF is 3 (because there are 3 numbers).

SIZEOF is 6 (3 items × 2 bytes each).

IV. SIZEOF OPERATOR

The SIZEOF operator returns a value that is equivalent to multiplying LENGTHOF by TYPE. For example:

IntArray is indeed an array of 32 words. Each word is 16 bits or 2 bytes in size. Therefore, the correct calculation for SIZEOF intArray should be:

SIZEOF intArray = 32 * 2 = 64

So, the correct value for EAX should be 64.

I know for beginners your brains have bluescreened right here, let me re-explain properly.  

SIZEOF, LENGTHOF, and TYPE — Explained Like a Human

At first glance, SIZEOF, LENGTHOF, and TYPE sound intimidating… but they’re really just answering three very simple questions about your data.

Let’s break them apart before we put them together.

I. LENGTHOF — “How many items are there?”