0

I learned that the floating point error involves the arithmetic operation, but when I am stepping through the problems and checking all the registers everything is doing what it is suppose to do. I am trying to find the median from 1 to n. I go the first median printed, but then it results in a floating point error when going back into the loop.

    SECTION .data

Median:
num:    db "%d " , 10, 0

    SECTION .bss
    SECTION .text

    extern printf
    global main

main:
    nop
    push ebp
    mov ebp, esp
    push ebx
    push esi
    push edi
    ;boiler plate
    ;start of main code
                ;first loop to adding summation
    xor edx, edx
    xor eax, eax
    xor esi, esi
    xor ecx, ecx
    xor edi, edi
    xor ebx, ebx
    xor ebp, ebp
L1: ;n-1 counter

    mov ecx, 2
    inc ebx ;start of n // counter
    mov eax, ebx
    sub eax, 1
    mul ebx
    div ecx
    mov esi, eax ;value from here

    mov ebp, ebx ;start of n+1 to add to see if equal
    add ebp, 1 ;n+1
    cmp ebp, esi
    jne compare

compare: ;if n+1 does not equal to esi add next value to n+1

    mov eax, ebp
    add eax, 1
    add ebp, eax
    cmp ebp, esi
    je print
    jmp lessthan

lessthan:   
    cmp ebp, esi
    jle compare
    jge L1

print:

    mov eax, ebx
    push eax
    push num
    call printf
    add esp, 8
    mov edi, ebx
    jmp L1

done:; finishes the loops/boilerplate after this
    pop edi
    pop esi
    pop ebx
    mov esp,ebp
    pop ebp
    ret
  • 2
    The floating point error is actually also called arithmetic exception (do you happen to be on a BSD/OSX system?). Anyway, the issue is likely because you don't properly clear _EDX_ when looping back to `L1`. It likely works the first time through since you clear _EDX_ before `L1`.Be aware that `div ecx` divides the 64-bit contents of _EDX:EAX_ by _ECX_ . The remainder is put in _EDX_ and _EAX_ contains the quotient. If the division can't be represented in 32-bit you'll get an exception (on your system is manifests s a floating point error even though it is really an integer division overflow). – Michael Petch Oct 04 '16 at 05:58
  • 2
    This question is closely related to: http://stackoverflow.com/questions/38416593/why-should-edx-be-0-before-i-use-div-opcode/38416896#38416896 – Michael Petch Oct 04 '16 at 06:04
  • I am be ubuntu 16.04. I am also stepping through with gdb to see what each of the registers are holding during the procedure and i do not see an overflow. I will look into it again. I will make some adjustments and keep debugging to see if there are any results. And I really appreciate your help! – Faith in Code Oct 04 '16 at 17:57
  • There won't be "junk", since MUL wrote its 64-bit result to EDX:EAX. But using DIV to divide by a constant power of 2 is terrible, don't do that in the first place. Use `shrd eax, edx, 1` / `shr edx, 1` to right-shift the 64-bit EDX:EAX produced by MUL. Or if you don't care about the upper half of the multiply result, ignore EDX and just use `shr eax, 1`. – Peter Cordes Oct 04 '16 at 19:22
  • Thanks for all the input. I took all your advices and rewrote my code and got it to work. Much appreciated! – Faith in Code Oct 06 '16 at 19:59

0 Answers0