Hey there, let's break down this weird problem you're facing: when your loop count exceeds 1e9, your sum always lands on 1410065408 even though you declared sum as unsigned long long (which should handle values up to ~1.8e19—way larger than your iteration count).

First, let's decode that magic number: 1410065408 converts to hex as 0x54000000. This clue points straight to 32-bit register or logic overflow in your Sparc assembly code—since Sparc64 uses 64-bit registers by default, it's easy to accidentally slip into 32-bit operations without noticing.

Most Likely Causes #

1. Accidental 32-bit Register Usage #

Sparc64 lets you access the lower 32 bits of a 64-bit register with the l suffix (e.g., %o0l for the low half of %o0). If you used these 32-bit sub-registers for either your loop counter or sum accumulator, you'd hit a hard limit at 2^32-1 (~4.2e9). But wait—your issue triggers at 1e9, which is way below that. Oh right: if you treated a 64-bit loop count as a signed 32-bit integer, any value over 2^31-1 (2.1e9) becomes a negative number. That would break your loop condition, making it run a fixed number of times instead of your intended nLoop.

2. Incorrect Loop Termination Logic #

If your assembly uses a signed comparison (like cmp with bne that checks signed flags) for an unsigned loop count, values over 2^31-1 will be interpreted as negative. For example, if your loop checks "is counter less than nLoop", a negative nLoop (from 32-bit truncation) would make the condition true until the counter wraps around to a negative value—resulting in a fixed iteration count (which happens to be 1410065408 in your case).

3. Truncated Parameter Passing #

Double-check that you're passing nLoop to your assembly function as a full 64-bit value. If your C code incorrectly declares the assembly function's parameter as unsigned int instead of unsigned long long, the compiler will truncate the value to 32 bits before passing it to the assembly.

Fixes & Checks to Try #

Step 1: Audit Your Assembly for 64-bit Compliance #

Make sure you're using full 64-bit registers (no l suffix) for both the counter and sum. Here's a corrected example of a Sparc64 sum loop:

.global sum_loop
sum_loop:
    mov %o0, %g1          ! %g1 holds the full 64-bit nLoop
    mov 0, %g2            ! %g2 is our 64-bit sum, initialized to 0
loop:
    add %g2, 1, %g2       ! 64-bit increment of sum
    sub %g1, 1, %g1       ! Decrement loop counter (64-bit)
    cmp %g1, 0
    bne loop              ! Keep looping until counter hits 0
    nop
    mov %g2, %o0          ! Return the full 64-bit sum
    retl
    nop

Step 2: Verify C Function Declarations #

Ensure your C code properly declares the assembly function with the right types:

#include <stdio.h>

// Explicitly use unsigned long long for both parameter and return value
unsigned long long sum_loop(unsigned long long nLoop);

int main() {
    unsigned long long n = 1000000001ULL; // Use ULL suffix to ensure 64-bit literal
    unsigned long long result = sum_loop(n);
    printf("Result: %llu\n", result);
    return 0;
}

Step 3: Check for Signed vs Unsigned Comparisons #

If your loop uses a comparison that checks signed flags (like bl for "branch if less than"), switch to unsigned comparisons if needed. For Sparc64, you can use cmpu for unsigned comparisons instead of cmp (which is signed). For example:

cmpu %g1, 0  ! Unsigned comparison of counter vs 0
bne loop
nop

Why That Exact Number? #

1410065408 is the result of your loop running a fixed number of times after the 32-bit signed overflow. When your nLoop gets truncated to a negative 32-bit value, your loop condition ends up executing exactly (unsigned int)(-truncated_nLoop) times—and in your case, that lands on 1410065408. Fixing the 64-bit handling will make the sum match your intended nLoop every time.

内容的提问来源于stack exchange，提问作者user1773603