0

The problem with segmentation fault has been solved, however there still remains a question of faulty algorithm itself which sorts numbers correctly but puts some of the biggest ones on the top of the file. For example numbers:

 600196455
1215535209
1560271953
1491899466
2093817641
3618330810
 519782898
3779504611
1656881276
 670566484

after sorting become:

3618330810
3779504611
 519782898
 600196455
 670566484
1215535209
1491899466
1560271953
1656881276
2093817641

OLD I am trying to implement an assembler program to read 32bit numbers from a file(maximum 32768 numbers), sort them using selection sort and save them to a specified file. So far I have successfully written parts that read and write data however there is an error in my sorting algorithm which results in a segmentation fault.

I am using 32bit Fedora, i386 processor, NASM assembler.

Thanks

My code looks as following

section .text
global _start

_start:
    ; read from input
    mov eax, 3
    mov ebx, 0
    mov ecx, array
    mov edx, 4*32768
    int 80h

    mov [fileLength], eax
    shr eax, 2
    mov [numbersCount], eax
    mov [numbersCount1], eax
    dec dword [numbersCount1]

    ; sort
    mov ebp, array
    xor ecx, ecx
    for1:
            mov dword [min], ecx
            xor edx, edx
            mov edx, ecx
            inc edx
            for2:
                    xor esi, esi
                    mov esi, dword [min]
                    mov eax, dword [ebp+4*edx]
                    mov ebx, dword [ebp+4*esi]
                    cmp eax, ebx
                    jge if1
                    mov dword [min], edx
                    if1:
                            inc edx
                            cmp edx, [numbersCount]
                            jl for2
                    xor ebx, ebx
                    xor edx, edx
                    mov ebx, dword [min]

                    mov eax, dword [ebp+4*ebx]
                    mov edx, dword [ebp+4*ecx]
                    mov dword [ebp+4*ebx], edx
                    mov dword [ebp+4*ecx], eax

                    inc ecx
                    cmp ecx, [numbersCount1]
                    jl for1
                    ret
    ; write to output
    mov eax, 4
    mov ebx, 1
    mov ecx, array
    mov edx, [fileLength]
    int 80h

    ; exit to linux
    mov     eax,1
    mov     ebx,0
    int     80h

; initialized data section
; use directives DB (byte), DW (word), DD (doubleword), DQ (quadword)
section .data

; uninitialized data section
; use directives RESB (byte), RESW (word), RESD (doubleword), RESQ (quadword)
section .bss
    fileLength resd 1
    numbersCount resd 1
    numbersCount1 resd 1
    min resd 1
    array resd 32768
    item resd 1
user1832258
  • 51
  • 1
  • 5

1 Answers1

0

Your using ret without having used call. call is used to push the current location to the stack. ret basically just goes back to the thing on the top of the stack, as there is no call, the top of the stack is whatever you last put on it, so it will jump to a weird location where as I assume your OS is reasonable, it segfaults before the program can do any damage.

Code Bundle
  • 282
  • 1
  • 2
  • 14
  • Thanks. I've got one more question. The program works but it sorts in a weird way. The problem starts when I have 6 numbers or more and what happens is it puts a couple (depends on the numbers' count) of biggest numbers on the top. So my "sorted list" looks like that: 60, 4, 5, 12, 22, 43. The problem seems to occur in the first step. I've spent quite some time looking for the error but I can't find it. Do you see it by any chance? – user1832258 Nov 25 '12 at 16:28
  • To save me time reading the code, what sorting algorithm are you using? – Code Bundle Nov 25 '12 at 17:01
  • It is selection sort for 32 bit numbers – user1832258 Nov 25 '12 at 17:21
  • Ok. I solved it. I changed instructions 'jge' and 'jl' to 'jae' and 'jb' respectively. However I do not understand it fully. According to definition of those instructions jge works for signed and jae for unsigned ints. In my case there are no negative numbers luckily, but what happens if I have to operate on big negative numbers? How to handle that? – user1832258 Nov 27 '12 at 21:54