Intergalactic Transmission in Arm64-assembly: Complete Solution & Deep Dive Guide

---

Mastering Arm64 Assembly: The Complete Guide to Parity Bits and Error Detection

Parity bit error detection in Arm64 assembly is a fundamental technique for ensuring data integrity during transmission. It involves adding a single bit to a byte, making the total count of '1' bits even, allowing a receiver to detect single-bit errors by simply recalculating the parity.

Imagine sending a critical command to a deep-space probe millions of miles away. The message, a stream of ones and zeros, travels through the cosmic void, vulnerable to solar flares, gravitational waves, and stray radiation. A single flipped bit could corrupt the entire command, turning "deploy solar panels" into "fire retro-rockets"—a catastrophic failure. This isn't just science fiction; it's the fundamental challenge of data integrity.

In high-stakes environments, you can't afford ambiguity. You need absolute control over the data, down to the individual bit. This is where the raw power of assembly language shines. In this comprehensive guide, we'll dive deep into the Arm64 instruction set to build a robust data transmission system from the ground up, mastering the classic and highly efficient art of parity bits for error detection. You'll learn not just how it works, but why it's a cornerstone of reliable communication.

---

What Is Parity Bit Error Detection?

At its core, a parity bit is a simple form of error checking. It's an extra bit added to a binary message to ensure that the total number of 1-bits in the message is either always even or always odd. This agreement between the sender (transmitter) and receiver forms the basis of the check.

There are two types of parity:

• Even Parity: The parity bit is set to 1 if the number of ones in the data bits is odd, making the total number of ones (including the parity bit) an even number. If the number of ones is already even, the parity bit is 0.
• Odd Parity: The parity bit is set to 1 if the number of ones in the data bits is even, making the total number of ones an odd number. If the number of ones is already odd, the parity bit is 0.

In the context of the kodikra.com learning module we're tackling, we will focus on even parity. The transmitter will calculate and append a parity bit to every 7 bits of data, creating an 8-bit byte for transmission. The receiver will then perform the same calculation on the received data bits and check if its calculated parity bit matches the one that was sent.

A Simple Example

Let's say we want to transmit the 7-bit data chunk 1011001.

1. Count the ones: The data 1011001 has four '1's.
2. Determine Parity (Even): Since four is an even number, the parity bit should be 0 to keep the total count of ones even.
3. Construct the Transmission Byte: The parity bit is typically placed as the least significant bit (LSB) or most significant bit (MSB). In our case, it will be the LSB. The 7 data bits are shifted left, and the parity bit is added. The final 8-bit byte becomes 10110010.

If the receiver gets 10110010, it separates the data (1011001) from the parity bit (0). It counts the ones in the data (four), determines the parity should be 0, and sees that it matches. The data is considered valid.

However, if a single bit flipped in transit, say to 10110110, the receiver would count five ones in the data part. It would calculate an expected parity bit of 1, which does not match the received parity bit of 0. An error is detected!

The Logic Flow of Parity Calculation

Here is a conceptual diagram illustrating the transmitter's logic for a single 7-bit chunk of data.

    ● Start with 7 data bits
    │
    ▼
  ┌────────────────────────┐
  │ Count the '1's         │
  │ e.g., "1101001" -> 4 ones │
  └──────────┬─────────────┘
             │
             ▼
    ◆ Is the count odd?
   ╱                   ╲
  Yes (e.g., 3)       No (e.g., 4)
  │                      │
  ▼                      ▼
┌─────────────────┐  ┌─────────────────┐
│ Set Parity Bit = 1│  │ Set Parity Bit = 0│
└─────────────────┘  └─────────────────┘
  │                      │
  └──────────┬───────────┘
             │
             ▼
  ┌──────────────────────────┐
  │ Combine 7 data bits with │
  │ the 1 parity bit         │
  └──────────┬───────────────┘
             │
             ▼
    ● Transmit 8-bit byte

---

Why Use Arm64 Assembly for Bit-Level Operations?

In an age of high-level languages and powerful frameworks, why would we drop down to assembly language to handle something like parity bits? The answer lies in control, efficiency, and the nature of the systems where such operations are most critical.

Unmatched Performance and Efficiency

Assembly language provides a direct, one-to-one mapping with the processor's machine code instructions. There is no abstraction layer, no runtime, and no garbage collector. This means you have ultimate control over the CPU's resources.

• Speed: For tasks involving heavy bit manipulation, like encoding/decoding, cryptography, or signal processing, custom assembly routines can outperform compiled code from higher-level languages by avoiding overhead and using specialized instructions.
• Code Size: Assembly code can be incredibly compact. This is crucial for embedded systems, microcontrollers, and IoT devices where memory is a scarce and precious resource. A space probe's flight computer is a perfect example of such a resource-constrained environment.
• Power Consumption: Efficient code that executes in fewer clock cycles directly translates to lower power consumption. For battery-powered devices or massive server farms, this is a significant factor.

Direct Hardware Access

Arm64 assembly allows you to directly manipulate registers, which are the fastest memory storage locations available to the CPU. The logic for our intergalactic transmitter involves constantly shifting, masking, and combining bits. Performing these actions directly in registers is orders of magnitude faster than manipulating variables in main memory.

A Foundation for Understanding

Even if you don't write assembly daily, understanding it makes you a better programmer. It demystifies what happens "under the hood" when you compile your C++, Rust, or Go code. You gain a deeper appreciation for data alignment, cache performance, and how high-level constructs translate into low-level machine operations.

For this specific kodikra module, Arm64 is the perfect choice. It's the architecture powering everything from Apple Silicon Macs and iPhones to the world's most powerful supercomputers and countless embedded devices. Mastering its instruction set is a valuable and future-proof skill.

---

How the Transmitter Works: A Deep Dive into transmit_sequence

The transmitter's job is to take a stream of raw message bytes, process them 7 bits at a time, calculate the correct even parity for each chunk, and write the resulting 8-bit bytes (7 data + 1 parity) into an output buffer. This process is more complex than it sounds because the input message is a continuous stream, not pre-packaged 7-bit chunks.

We need a mechanism to buffer bits as they are read from the input. Let's analyze the provided solution from the kodikra.com curriculum line by line.

The Assembly Code for `transmit_sequence`

.text
.globl transmit_sequence

/* extern int transmit_sequence(uint8_t *buffer, const uint8_t *message, int message_length); */
/* x0: buffer, x1: message, x2: message_length */
transmit_sequence:
    mov     x15, x0             /* Save buffer's start address in a callee-saved register */
    cbz     x2, .transmit_success /* If message_length is zero, we're done. */

    mov     x7, 7               /* Constant 7 for counting down */
    mov     x10, xzr            /* x10: number of pending bits in our buffer (starts at 0) */
    mov     x12, xzr            /* x12: value of pending bits (starts at 0) */
    b       .transmit_read

.transmit_odd_parity:
    orr     x12, x12, 1         /* Set the LSB (parity bit) to 1 */

.transmit_even_parity:
    strb    w12, [x15], 1       /* Store the byte (w12) to buffer and post-increment buffer pointer */
    mov     x10, xzr            /* Reset pending bit count */
    mov     x12, xzr            /* Reset pending bit value */
    b       .transmit_read

.transmit_loop:
    mov     x11, x1             /* Copy message pointer to a scratch register */
    ldr     x11, [x11]          /* Dereference to get the current message byte */
    mov     x9, 8               /* We process 8 bits per message byte */

.transmit_inner_loop:
    lsl     x12, x12, 1         /* Make space for the new bit */
    ubfx    x13, x11, x9, 1     /* Extract the most significant bit we haven't processed */
    orr     x12, x12, x13       /* Add the new bit to our pending bits */
    add     x10, x10, 1         /* Increment pending bit count */
    cmp     x10, x7             /* Have we collected 7 bits? */
    b.ne    .transmit_inner_loop_continue /* If not, continue inner loop */

    /* We have 7 bits, now calculate parity */
    eor     x13, x12, x12, lsr 4
    eor     x13, x13, x13, lsr 2
    eor     x13, x13, x13, lsr 1
    and     x13, x13, 1         /* x13 now holds the parity (1 if odd, 0 if even) */

    lsl     x12, x12, 1         /* Make space for the parity bit */
    cbz     x13, .transmit_even_parity /* If parity is 0 (even), jump */
    b       .transmit_odd_parity

.transmit_inner_loop_continue:
    sub     x9, x9, 1           /* Decrement inner loop counter */
    cbnz    x9, .transmit_inner_loop /* Continue if more bits in this byte */

.transmit_read:
    sub     x2, x2, 1           /* Decrement message_length */
    cmp     x2, -1
    b.eq    .transmit_finish    /* If we've processed all bytes, finish up */
    add     x1, x1, 1           /* Increment message pointer */
    b       .transmit_loop

.transmit_finish:
    cbz     x10, .transmit_success /* If no pending bits, we are truly done */
    /* Handle leftover bits */
    lsl     x12, x12, 7
    lsr     x12, x12, x10       /* Right-align the remaining bits */
    eor     x13, x12, x12, lsr 4
    eor     x13, x13, x13, lsr 2
    eor     x13, x13, x13, lsr 1
    and     x13, x13, 1
    lsl     x12, x12, 1
    cbz     x13, .transmit_even_parity_final
    orr     x12, x12, 1

.transmit_even_parity_final:
    strb    w12, [x15]          /* Store the final byte */

.transmit_success:
    mov     x0, xzr             /* Return 0 for success */
    ret

Code Walkthrough and Logic Explanation

1. Initialization

• mov x15, x0: The function arguments arrive in registers x0 (buffer), x1 (message), and x2 (message_length). x0 is a volatile register, meaning its value can be changed by functions we call. We save the buffer address in x15, a callee-saved register that we can rely on.
• cbz x2, .transmit_success: A quick check. If the message length is zero, there's nothing to do. We jump straight to the success exit.
• mov x7, 7: Loads the constant 7 into register x7. This will be our target number of bits to collect before forming a transmission byte.
• mov x10, xzr: Initializes x10 to zero. This register acts as our "pending bit counter".
• mov x12, xzr: Initializes x12 to zero. This register is our "bit accumulator" or buffer, where we will build up the 7 data bits.

2. The Main Loop Structure (`.transmit_read` and `.transmit_loop`)

The code uses a nested loop structure. The outer loop (`.transmit_read` -> `.transmit_loop`) iterates through each byte of the input message. The inner loop (`.transmit_inner_loop`) iterates through each bit of the current input byte.

• sub x2, x2, 1: Decrements the remaining message length. We do this at the start of the loop.
• ldr x11, [x11]: Loads the current byte from the message into x11.
• mov x9, 8: Initializes the inner loop counter to 8, for the 8 bits in the byte.

3. The Inner Loop: Bit Buffering

This is the core logic where individual bits are extracted and accumulated.

• lsl x12, x12, 1: Logical Shift Left. This shifts all bits in our accumulator (x12) one position to the left, effectively making room for a new bit at the LSB position. It's like multiplying by 2.
• ubfx x13, x11, x9, 1: Unsigned Bitfield Extract. This is a powerful instruction. It extracts 1 bit from x11 starting at position x9. Since x9 counts down from 8, this effectively reads the bits from MSB to LSB. The extracted bit is placed in x13.
• orr x12, x12, x13: Bitwise OR. This merges the new bit from x13 into the empty LSB position of our accumulator x12.
• add x10, x10, 1: Increments our pending bit counter.
• cmp x10, x7: Compares the pending bit count to our target of 7.
• b.ne .transmit_inner_loop_continue: If we have not collected 7 bits yet, we branch to the end of the inner loop to process the next bit from the source byte.

The Bit Accumulation Process

This visual flow shows how the transmitter buffers bits from the input message until it has a full 7-bit chunk ready for parity calculation.

    ● Start
    │
    ▼
  ┌──────────────────┐
  │ Read Input Byte  │
  │ e.g., 0xA9 (10101001) │
  └────────┬─────────┘
           │
           ▼
  ┌─ Inner Loop (8 times) ─┐
  │                        │
  │   ▼ Extract MSB        │
  │   │                    │
  │   ▼ Add to Accumulator │
  │   │                    │
  │   ▼ Increment Bit Count│
  │                        │
  └────────┬───────────────┘
           │
           ▼
    ◆ Bit Count == 7?
   ╱                  ╲
  No                    Yes
  │                      │
  │                      ▼
  │              ┌───────────────────┐
  │              │ Calculate Parity  │
  │              │ & Form 8-bit Byte │
  │              └────────┬──────────┘
  │                       │
  │                       ▼
  │                  ┌────────────┐
  │                  │ Write Byte │
  │                  │ Reset      │
  │                  └────────────┘
  │                               │
  └─────────────┬─────────────────┘
                │
                ▼
      ◆ Any more input bytes?
     ╱                         ╲
    No                          Yes
    │                            │
    ▼                            └─> Back to Read Input Byte
  ┌────────────┐
  │ Handle     │
  │ Leftovers  │
  └─────┬──────┘
        │
        ▼
      ● End

4. Parity Calculation and Transmission

Once 7 bits are collected, the code jumps into this block.

• eor x13, x12, x12, lsr 4: This is a classic bit-twiddling hack for calculating parity (population count modulo 2). It XORs the top half of the bits with the bottom half.
• eor x13, x13, x13, lsr 2
• eor x13, x13, x13, lsr 1: These steps continue the process, folding the bits onto each other.
• and x13, x13, 1: After the XOR folding, the LSB of x13 will be 1 if the original number had an odd number of set bits, and 0 if it had an even number. This is our parity!
• lsl x12, x12, 1: We shift our 7 data bits left one more time to make room for the parity bit at the LSB.
• cbz x13, .transmit_even_parity: If the calculated parity in x13 is 0 (meaning the data already had an even number of ones), we jump to the section that writes the byte as-is.
• b .transmit_odd_parity: Otherwise, we jump to the odd parity handler.
• .transmit_odd_parity: orr x12, x12, 1: Here, we set the LSB to 1 to make the total count of ones even.
• .transmit_even_parity: strb w12, [x15], 1: Store Byte. This writes the lower 8 bits of our final value (w12) to the memory address pointed to by our buffer register x15. The , 1 part signifies post-indexing, meaning the address in x15 is automatically incremented by 1 after the write.
• mov x10, xzr and mov x12, xzr: The accumulator and counter are reset, ready for the next 7 bits.

5. Handling Leftovers (`.transmit_finish`)

What if the total number of bits in the message is not a multiple of 7? The main loop will finish, but there might be 1 to 6 bits left in our accumulator (x12). This section handles that case by padding the remaining bits with zeros, calculating parity, and writing one final byte.

---

How the Receiver Works: Decoding with decode_message

The receiver's function is the mirror image of the transmitter. It reads 8-bit bytes from the incoming transmission, validates the parity, extracts the 7 data bits, and packs them into a clean output message buffer. If it ever detects a parity mismatch, it must stop immediately and report an error.

The Assembly Code for `decode_message`

.equ WRONG_PARITY, -1
.text
.globl decode_message

/* extern int decode_message(uint8_t *message, const uint8_t *buffer, int buffer_length); */
/* x0: message, x1: buffer, x2: buffer_length */
decode_message:
    mov     x15, x0             /* Save message pointer */
    cbz     x2, .decode_success

    mov     x10, xzr            /* Pending bit count */
    mov     x12, xzr            /* Pending bit value */
    b       .decode_read

.decode_loop:
    mov     x11, x1
    ldrb    w11, [x11]          /* Load a byte from the buffer */

    /* Parity check */
    eor     w13, w11, w11, lsr 4
    eor     w13, w13, w13, lsr 2
    eor     w13, w13, w13, lsr 1
    tst     w13, 1              /* Test the LSB (overall parity) */
    b.ne    .decode_wrong_parity /* If not zero, parity is odd, which is an error */

    /* Parity is OK, process the 7 data bits */
    mov     x9, 7               /* 7 bits to process */
    lsr     x11, x11, 1         /* Shift out the parity bit */

.decode_inner_loop:
    lsl     x12, x12, 1         /* Make room in our accumulator */
    ubfx    x13, x11, x9, 1     /* Extract MSB of the data */
    orr     x12, x12, x13       /* Add it to accumulator */
    add     x10, x10, 1         /* Increment pending bit count */
    cmp     x10, 8              /* Have we collected 8 bits (a full byte)? */
    b.ne    .decode_inner_loop_continue

    /* We have a full byte, write it */
    strb    w12, [x15], 1       /* Store byte to message and increment pointer */
    mov     x10, xzr            /* Reset pending bit count */
    mov     x12, xzr            /* Reset pending bit value */

.decode_inner_loop_continue:
    sub     x9, x9, 1
    cbnz    x9, .decode_inner_loop

.decode_read:
    sub     x2, x2, 1
    cmp     x2, -1
    b.eq    .decode_success
    add     x1, x1, 1
    b       .decode_loop

.decode_wrong_parity:
    mov     x0, WRONG_PARITY
    ret

.decode_success:
    mov     x0, xzr
    ret

Code Walkthrough and Logic Explanation

1. Initialization

Similar to the transmitter, it saves the output message pointer in x15 and handles the zero-length case. It also initializes a pending bit counter (x10) and accumulator (x12) to zero.

2. Main Loop and Parity Validation

• ldrb w11, [x11]: Loads one byte from the input buffer into w11.
• The next three eor instructions perform the exact same parallel parity calculation as the transmitter, but this time on the *entire 8-bit received byte*.
• tst w13, 1: The Test instruction performs a bitwise AND but discards the result, only setting the condition flags. We are testing the LSB of the final folded XOR value. For an even parity byte, the result of this entire calculation should be 0.
• b.ne .decode_wrong_parity: Branch if Not Equal (to zero). If the test result was not zero, it means the received byte had an odd number of set bits—a parity error. The code immediately branches to the error handling routine.

3. Data Extraction and Re-packing

If the parity check passes, we proceed.

• lsr x11, x11, 1: Logical Shift Right. This shifts the 8-bit value one position to the right, discarding the LSB (the parity bit) and leaving us with the 7 clean data bits.
• The subsequent inner loop is the reverse of the transmitter's. It extracts the 7 data bits one by one and accumulates them in x12.
• cmp x10, 8: It waits until it has collected 8 clean data bits (a full byte for the final message).
• strb w12, [x15], 1: Once a full byte is assembled in the accumulator, it's written to the output message buffer, and the process repeats.

4. Error and Success Handling

• .decode_wrong_parity: This section simply loads the predefined constant WRONG_PARITY (-1) into the return register x0 and returns, signaling failure.
• .decode_success: This section loads 0 into x0 and returns, signaling success.

---

Real-World Applications and Limitations

While our "Intergalactic Transmission" scenario is a fun way to frame the problem, parity checking is a real technique used in many foundational technologies.

• Serial Ports (RS-232): Older serial communication protocols used in industrial machinery, networking hardware, and embedded systems often include a parity bit in their framing.
• Early Memory Modules: Before the widespread adoption of more advanced ECC (Error-Correcting Code) memory, some systems used parity RAM to detect memory errors and halt the system to prevent data corruption.
• Simple Network Protocols: Some basic, low-overhead communication protocols might use a parity check as a lightweight method of ensuring data hasn't been garbled.

Pros & Cons of Parity Checking

Like any technology, parity checking has its trade-offs. It's important to understand its limitations to know when it's appropriate to use.

Pros	Cons
Extremely Simple to Implement: The logic is straightforward and requires very few computational resources, making it ideal for low-power microcontrollers.	Cannot Correct Errors: It can only detect that an error occurred, not which bit is wrong. The only recourse is to request a re-transmission of the data.
Very Low Overhead: It only adds one bit for every 7 bits of data (~14% overhead), which is computationally cheap.	Fails on Even Number of Bit Flips: If two bits flip (e.g., a 0 becomes a 1 and a 1 becomes a 0), the parity remains the same, and the error goes completely undetected.
Fast Calculation: As seen in our assembly code, parity can be calculated in just a handful of clock cycles.	Not Suitable for Noisy Environments: In environments where multiple bit errors are likely (e.g., wireless communication), parity checking is insufficient.

For more robust error detection and correction, engineers turn to more advanced techniques like Checksums, Cyclic Redundancy Checks (CRC), and Error-Correcting Codes (ECC) like Hamming codes or Reed-Solomon codes, which can not only detect but also correct a certain number of errors on the fly.

---

Frequently Asked Questions (FAQ)

What is the difference between even and odd parity?

Even parity ensures the total number of '1' bits in a transmission unit (data + parity bit) is an even number. Odd parity ensures the total number of '1' bits is an odd number. The choice between them is a matter of protocol design; neither is inherently superior, but both sender and receiver must agree on which one to use.

Why can't parity checking detect an error if two bits flip?

Parity is based on the oddness or evenness of the count of set bits. If one bit flips, an even count becomes odd, or an odd count becomes even, which is detectable. If two bits flip, an even count remains even, and an odd count remains odd, making the error invisible to the parity check mechanism. For example, if 10110010 (4 ones, even) becomes 10111110 (6 ones, still even), the error is missed.

Can a parity bit correct an error?

No. A parity bit can only signal that an error has occurred. It contains no information about *which* bit was flipped. More advanced schemes like Hamming codes add multiple check bits that, when analyzed together, can pinpoint and correct single-bit errors.

Is there a more direct way to count bits in Arm64 assembly?

Yes, for general-purpose bit counting (population count), modern ARMv8 architectures include the CNT instruction. For example, CNT v1.8b, v0.8b counts the number of set bits in each byte of a SIMD register. However, for parity, we only need to know if the count is odd or even. The bit-twiddling XOR method shown in the solution is often faster for this specific purpose as it avoids counting entirely and directly computes the parity in just a few instructions.

Why is the parity bit placed as the least significant bit (LSB) in this example?

Placing the parity bit at the LSB is a common convention that simplifies processing. It allows the receiver to easily isolate the 7 data bits with a single right-shift instruction (lsr x11, x11, 1), which is computationally very cheap. The transmitter also benefits as it can append the parity bit with a simple OR instruction (orr x12, x12, 1) after shifting the data bits left.

Is parity checking still relevant in modern computing?

While it has been largely superseded by CRC and ECC in high-speed networking and main memory, parity checking remains relevant in specific niches. It's used in some embedded systems, industrial control buses (like CAN bus), and legacy protocols where simplicity and low overhead are more important than robust error correction. It serves as an excellent educational tool for understanding the fundamentals of data integrity.

---

Conclusion

We've journeyed from the high-level concept of intergalactic communication down to the fundamental bit-level operations that make it reliable. By implementing a transmitter and receiver in Arm64 assembly, you've gained practical experience with essential low-level programming techniques: register management, bitwise operations, control flow, and memory manipulation.

You learned that parity checking is a fast and efficient, albeit simple, method for detecting single-bit errors. More importantly, you saw how the elegance and power of the Arm64 instruction set allow for highly optimized solutions to complex data manipulation problems. This knowledge is not just academic; it's the foundation upon which secure, efficient, and reliable software is built, from the smallest IoT device to the largest supercomputer.

Disclaimer: All code and examples are based on the Armv8-A architecture. The behavior of specific instructions may vary on other architectures. The logic presented is part of the exclusive learning curriculum from kodikra.com.

Continue your journey on the kodikra Arm64-assembly learning path.

Explore more advanced Arm64 assembly concepts in our complete guide.

---

Published by Kodikra — Your trusted Arm64-assembly learning resource.