problem performing recursive call in quick sort assembly - sorting

I'm having a problem implementing quicksort in assembly, when I'm trying to perform the second recursive call to qsort(arr,pi+1,high) I don't know why, but it exits the recursion too early.
I've tried using the stack and writing helper functions, but everything I've tied created new problems. When debbuging, I see that I exit the function when %ebx = 4 and %ecx = 5 and the array is almost sorted array ={10,30,40,50,70,90,80} - I need only to perform the last swap when %ebx = 5 and %ecx = 6, but it exits before, and I don't understand why it won't go back to when %ecx was 6.
I thought perhaps the problem is when I'm making the comparisons between high and low, but If I change those, I'm having different problems (it exists too early the first recursive call). perhaps anyone has an idea what's wrong with my code?
here's my code:
.data
array: .int 10, 80, 30, 90, 40, 50, 70
size: .int 7
.text
.global main
main:
movl $0, %ebx # low index
movl (size), %ecx # high index
dec %ecx # ecx = size -1
qsort:
cmp %ecx, %ebx # high > low
jge end
movsx %ecx, %r13 # push high
movsx %ebx, %r12 # push low
call partition # rax now is the pivot
movq %r12, %rbx # pop low
movl %eax, %ecx # prepare new high = pi
subl $1, %ecx # high = pi-1
call qsort # qsort(arr,low,pi-1)
movl %eax,%ebx # push new low = pi+1
inc %ebx
call qsort # qsort(arr,pi+1,high)
ret
partition:
movq %r12, %rax # get low
movq %r13, %rbx # get high
movl %eax, %ecx # j = low
subl $1, %eax # i = low-1
movl array(,%ebx,4), %edx # pivot = array[high]
swap_loop:
cmp %ebx, %ecx # high > j
jge swap_greater
movl array(,%ecx,4), %esi # esi = array[j]
cmp %edx, %esi # pivot > array[j] ?
jge loops # jmp if array[j] > pivot
inc %eax # i++
# swap
movsx %esi, %rsi
pushq %rsi
movl array(,%eax,4), %edi # edi = array[i]
movl %edi, array(,%ecx,4) # array[j]=array[i]
pop %rsi
movl %esi, array(,%eax,4) # array[i]= previous array[j]
loops:
inc %ecx # j++
jmp swap_loop
swap_greater:
inc %eax
movsx %edx, %rdx
pushq %rdx
movl array(,%eax,4), %edi # edi = array[i+1]
movl %edi, array(,%ebx,4) # array[high]=array[i+1]
pop %rdx
movl %edx, array(,%eax,4) # array[i+1]= previous array[high]
dec %eax
end_p:
inc %eax
ret
end:
inc %ecx
movsx %ecx, %r13 # update high
ret
edit: as Peter Cordes has pointed out - I need to work with the stack in order to retrieve the parameters when I go back from the recursive calls. after re-writing my code using the stack, I have a new problem, I always pop out the same thing on the second recursive call. I don't understand why it doesn't do the "recursive folding" like in C, when I look at the stack there's something weird, since I'm not seeing the values as I excpect ( I excpect to see layers or rax-high-low-rax-high-low...etc) but instead there are those numbers:
native process 42032 In: second_rec L?? PC: 0x4005ea
0x7fffffffdeb0: 0x0000000000000000 0x0000000000000001
0x7fffffffdec0: 0x0000000000000002 0x00000000004005ef
0x7fffffffded0: 0x0000000000000000 0x0000000000000002
0x7fffffffdee0: 0x0000000000000001 0x00000000004005df
0x7fffffffdef0: 0x0000000000000000 0x0000000000000001
0x7fffffffdf00: 0x0000000000000002 0x00000000004005df
0x7fffffffdf10: 0x0000000000000000 0x0000000000000002
0x7fffffffdf20: 0x0000000000000003 0x00000000004005df
0x7fffffffdf30: 0x0000000000000000 0x0000000000000003
0x7fffffffdf40: 0x0000000000000004 0x00007ffff7a05b97
0x7fffffffdf50: 0x0000000000000001 0x00007fffffffe028
0x7fffffffdf60: 0x0000000100008000 0x00000000004005a7
perhaps I'm not pushing\popping in the right timing, but from what I've understood, I'm pushing parameters before call, and popping them when I return from the call... does anyone have an idea what am I doing wrong? the new code:
.data
array: .int 10, 80, 30, 90, 40, 50, 70
size: .int 7
.text
.global main
main:
movl $0, %ebx # low index
movl (size), %ecx # high index
dec %ecx # ecx = size -1
qsort:
cmp %ecx, %ebx # high > low
jge end
movsx %ecx, %rcx # prepare high
movsx %ebx, %rbx # prepare low
pushq %rcx # push high
pushq %rbx # push low
call partition # rax now is the pivot
popq %rbx # pop low
popq %rcx # pop high
movsx %eax, %rax
pushq %rax # push pivot
movl %eax, %ecx # prepare new high = pi
subl $1, %ecx # pi-=1
movsx %ecx, %rcx
pushq %rcx # push high
pushq %rbx # push low
call qsort # qsort(arr,low,pi-1)
second_rec:
popq %rbx # pop low
popq %rcx # pop high
popq %rax # pop pivot
movl %eax, %ecx # high = pi
addl $1, %ecx # high = pi+1
pushq %rax # push pivot
pushq %rcx # push high
pushq %rbx # push low
call qsort # qsort(arr,pi+1,high)
addq $24, %rsp
ret
partition:
movq 8(%rsp), %rax # get low
movq 16(%rsp), %rbx # get high
movl %eax, %ecx # j = low
subl $1, %eax # i = low-1
movl array(,%ebx,4), %edx # pivot = array[high]
swap_loop:
cmp %ebx, %ecx # high > j
jge swap_greater
movl array(,%ecx,4), %esi # esi = array[j]
cmp %edx, %esi # pivot > array[j] ?
jge loops # jmp if array[j] > pivot
inc %eax # i++
# swap
movsx %esi, %rsi
pushq %rsi
movl array(,%eax,4), %edi # edi = array[i]
movl %edi, array(,%ecx,4) # array[j]=array[i]
pop %rsi
movl %esi, array(,%eax,4) # array[i]= previous array[j]
loops:
inc %ecx # j++
jmp swap_loop
swap_greater:
inc %eax
movsx %edx, %rdx
pushq %rdx
movl array(,%eax,4), %edi # edi = array[i+1]
movl %edi, array(,%ebx,4) # array[high]=array[i+1]
pop %rdx
movl %edx, array(,%eax,4) # array[i+1]= previous array[high]
dec %eax
end_p:
inc %eax
ret
end:
ret
Thank you very much everyone for your help!

Related

Correct usage of the RIP related addressing

I found example of code on assembly, which finds the maximum number in array named data_items but that example was for x86 and I tried to adapt it for x64 because 32 bit absolute addressing is not supported by 64 bit system.
To be short there are three actions:
lea data_items(%rip), %rdi #(1) Obtaining data_items address
add $4, %rdi #(2) Incrementing the pointer to 4 to read a next item
movl (%rdi), %eax #(3) Reading data at %rdi to %eax
The main questions:
Is it correct way to pointing? Can it produce error after code relocation?
If the %rip register constantly grows, why lea data_items(%rip), %rdi loads correct memory address? May be getting an offset by %rip have special meaning rather than "dataItems + %rip"?
Full adapted code here:
.section __DATA,__data
data_items:
.long 3,67,34,222,45,75,54,34,44,33,22,11,66,0
.section __TEXT,__text
.globl _main
_main:
lea data_items(%rip), %rdi #(1)
movl (%rdi), %eax
movl %eax, %ebx
start_loop:
cmpl $0, %eax
je loop_exit
add $4, %rdi #(2)
movl (%rdi), %eax #(3)
cmpl %ebx, %eax
jle start_loop
movl %eax, %ebx
jmp start_loop
loop_exit:
mov $0x2000001, %rax
mov $0, %rdi
syscall

Y86 Architecture Immediate VS Register Arithmetic Efficiency Question

I am working with a team in a Computer Architecture class on a Y86 program to implement multiplication function imul. We have a block of code that works, but we are trying to make it as execution-time efficient as we can. Currently our block looks like this for imul:
imul:
# push all used registers to stack for preservation
pushq %rdi
pushq %rsi
pushq %r8
pushq %r9
pushq %r10
irmovq 0, %r9 # set 0 into r9
rrmovq %rdi, %r10 # preserve rdi in r10
subq %rsi, %rdi # compare rdi and rsi
rrmovq %r10, %rdi # restore rdi
jl continue # if rdi (looping value/count) less than rsi, don't swap
swap:
# swap rsi and rdi to make rdi smaller value of the two
rrmovq %rsi, %rdi
rrmovq %r10, %rsi
continue:
subq %r9, %rdi # check if rdi is zero
cmove %r9, %rax # if rdi = 0, rax = 0
je imulDone # if rdi = 0, jump to end
irmovq 1, %r8 # set 1 into r8
rrmovq %rsi, %rax # set rax equal to initial value from rsi
imulLoop:
subq %r8, %rdi # count - 1
je imulDone # if count = 0, jump to end
addq %rsi, %rax # add another instance of rsi into rax, looped adition
jmp imulLoop # restart loop
imulDone:
# pop all used registers from stack to original values and return
popq %r10
popq %r9
popq %r8
popq %rsi
popq %rdi
ret
Right now our best idea is using immediate arithmetic instructions (isubq, etc) instead of normal OPq instructions with settings constants into registers and using those registers. Would this method be meaningfully more efficient in this particular instance? Thanks so much!

C++11 memory ordering support in GCC

GCC does not seem to support the different memory ordering settings as it generates the same code for relaxed, acquire and sequentially consistent.
I tried the following code with GCC 7.4 and 9.1:
#include <thread>
#include <atomic>
using namespace std;
atomic<int> z(0);
void Thr1()
{
z.store(1,memory_order_relaxed);
}
void Thr2()
{
z.store(2,memory_order_release);
}
void Thr3()
{
z.store(3);
}
//------------------------------------------
int main (int argc, char **argv)
{
thread t1(Thr1);
thread t2(Thr2);
thread t3(Thr3);
t1.join();
t2.join();
t3.join();
return 0;
}
When I generate assembly for the above, I get the following for each of the three functions:
_Z4Thr1v:
.LFB2992:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $16, %rsp
movl $1, -12(%rbp)
movl $0, -8(%rbp)
movl -8(%rbp), %eax
movl $65535, %esi
movl %eax, %edi
call _ZStanSt12memory_orderSt23__memory_order_modifier
movl %eax, -4(%rbp)
movl -12(%rbp), %edx
leaq z(%rip), %rax
movl %edx, (%rax)
mfence
nop
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE2992:
.size _Z4Thr1v, .-_Z4Thr1v
.globl _Z4Thr2v
.type _Z4Thr2v, #function
_Z4Thr2v:
.LFB2993:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $16, %rsp
movl $2, -12(%rbp)
movl $3, -8(%rbp)
movl -8(%rbp), %eax
movl $65535, %esi
movl %eax, %edi
call _ZStanSt12memory_orderSt23__memory_order_modifier
movl %eax, -4(%rbp)
movl -12(%rbp), %edx
leaq z(%rip), %rax
movl %edx, (%rax)
mfence
nop
leave
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE2993:
.size _Z4Thr2v, .-_Z4Thr2v
.globl _Z4Thr3v
.type _Z4Thr3v, #function
_Z4Thr3v:
.LFB2994:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
subq $16, %rsp
movl $3, -12(%rbp)
movl $5, -8(%rbp)
movl -8(%rbp), %eax
movl $65535, %esi
movl %eax, %edi
call _ZStanSt12memory_orderSt23__memory_order_modifier
movl %eax, -4(%rbp)
movl -12(%rbp), %edx
leaq z(%rip), %rax
movl %edx, (%rax)
mfence
nop
leave
.cfi_def_cfa 7, 8
ret
where all of the code ends in a memory fence instruction.
If you are interested in performance, then looking at non-optimised machine code is not going to get you anywhere. Here's what gcc -O2 generates:
Thr1():
mov DWORD PTR z[rip], 1
ret
Thr2():
mov DWORD PTR z[rip], 2
ret
Thr3():
mov DWORD PTR z[rip], 3
mfence
ret
As you can see, only sequentially consistent memory order requires mfence.

Storing keyboard Input in x64 assembly (Mac OS/X)

I have been trying for some time now to get a number from a keyboard and comparing it with a value on the stack. If it is correct it will print "Hello World!" and if incorrect, it should print out "Nope!". However, what happens now is no matter the input "jne" is called, nope is printed, and segfault. Perhaps one of you could lend a hand.
.section __DATA,__data
str:
.asciz "Hello world!\n"
sto:
.asciz "Nope!\n"
.section __TEXT,__text
.globl _main
_main:
push %rbp
mov %rsp,%rbp
sub $0x20, %rsp
movl $0x0, -0x4(%rbp)
movl $0x2, -0x8(%rbp)
movl $0x2000003, %eax
mov $0, %edi
subq $0x4, %rsi
movq %rsi, %rcx
syscall
cmp -0x8(%rbp), %edx
je L1
jne L2
xor %rbx, %rbx
xor %rax, %rax
movl $0x2000001, %eax
syscall
L1:
xor %rax, %rax
movl $0x2000004, %eax
movl $1, %edi
movq str#GOTPCREL(%rip), %rsi
movq $14, %rdx
syscall
ret
L2:
xor %eax, %eax
movl $0x2000004, %eax
movl $1, %edi
movq sto#GOTPCREL(%rip), %rsi
movq $6, %rdx
syscall
ret
I would start with this OS/X Syscall tutorial (The 64-bit part in your case). It is written for NASM syntax but the important information is the text and links for the SYSCALL calling convention. The SYSCALL table is found on this Apple webpage. Additional information on the standard calling convention for 64-bit OS/X can be found in the System V 64-bit ABI.
Of importance for SYSCALL convention:
arguments are passed in order via these registers rdi, rsi, rdx, r10, r8 and r9
syscall number in the rax register
the call is done via the syscall instruction
what OS X contributes to the mix is that you have to add 0x20000000 to the syscall number (still have to figure out why)
You have many issues with with your sys_read system call. The SYSCALL table says this:
3 AUE_NULL ALL { user_ssize_t read(int fd, user_addr_t cbuf, user_size_t nbyte); }
So given the calling convention, int fd is in RDI, user_addr_t cbuf (pointer to character buffer to hold return data) is in RSI, and user_size_t nbyte (maximum bytes buffer can contain) is in RDX.
Your program seg faulted on the ret because you didn't have proper function epilogue to match the function prologue at the top:
push %rbp #
mov %rsp,%rbp # Function prologue
You need to do the reverse at the bottom, set the result code in RAX and then do the ret. Something like:
mov %rbp,%rsp # \ Function epilogue
pop %rbp # /
xor %eax, %eax # Return value = 0
ret # Return to C runtime which will exit
# gracefully and return to OS
I did other minor cleanup, but tried to keep the structure of the code similar. You will have to learn more assembly to better understand the code that sets up RSI with the address for sys_read SYSCALL . You should try to find a good tutorial/book on x86-64 assembly language programming in general. Writing a primer on that subject is beyond the scope of this answer.
Code that might be closer to what you were looking for that takes the above into account:
.section __DATA,__data
str:
.asciz "Hello world!\n"
sto:
.asciz "Nope!\n"
.section __TEXT,__text
.globl _main
_main:
push %rbp #
mov %rsp,%rbp # Function prologue
sub $0x20, %rsp # Allocate 32 bytes of space on stack
# for temp local variables
movl $0x2, -4(%rbp) # Number for comparison
# 16-bytes from -20(%rbp) to -5(%rbp)
# for char input buffer
movl $0x2000003, %eax
mov $0, %edi # 0 for STDIN
lea -20(%rbp), %rsi # Address of temporary buffer on stack
mov $16, %edx # Read 16 character maximum
syscall
movb (%rsi), %r10b # RSI = pointer to buffer on stack
# get first byte
subb $48, %r10b # Convert first character to number 0-9
cmpb -4(%rbp), %r10b # Did we find magic number (2)?
jne L2 # If No exit with error message
L1: # If the magic number matched print
# Hello World
xor %rax, %rax
movl $0x2000004, %eax
movl $1, %edi
movq str#GOTPCREL(%rip), %rsi
movq $14, %rdx
syscall
jmp L0 # Jump to exit code
L2: # Print "Nope"
xor %eax, %eax
movl $0x2000004, %eax
movl $1, %edi
movq sto#GOTPCREL(%rip), %rsi
movq $6, %rdx
syscall
L0: # Code to exit main
mov %rbp,%rsp # \ Function epilogue
pop %rbp # /
xor %eax, %eax # Return value = 0
ret # Return to C runtime which will exit
# gracefully and return to OS

Which is more efficient. if(a-b >0) or if (a > b) [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
This might be a simple question.
I want to know which of the 2 statements will take less time to get executed.
if ( a - b > 0 ) or if ( a > b )
In the 1st case, the difference has to be computed and then it has to be compared with 0, while in the 2nd case, a and b are compared directly.
Thanks.
As Keith Thompson points out, the two are not the same. If a and b are unsigned, for example, a-b is always non-negative, making the statement equivalent to if(a != b).
Anyway, I did an unrealistic test:
int main() {
volatile int a, b;
if(a-b>=0)
printf("a");
if(a>b)
printf("b");
return 0;
}
Compile it with -O3. Here's the disassembly:
pushq %rbp
Ltmp2:
.cfi_def_cfa_offset 16
Ltmp3:
.cfi_offset %rbp, -16
movq %rsp, %rbp
Ltmp4:
.cfi_def_cfa_register %rbp
subq $16, %rsp
movl -4(%rbp), %eax
subl -8(%rbp), %eax
testl %eax, %eax
jle LBB0_2
## BB#1:
movl $97, %edi
callq _putchar
LBB0_2:
movl -4(%rbp), %eax
cmpl -8(%rbp), %eax
jle LBB0_4
## BB#3:
movl $98, %edi
callq _putchar
LBB0_4:
xorl %eax, %eax
addq $16, %rsp
popq %rbp
ret
At -O3, a-b>0 is still using one extra instruction.
Even if you compile it with an ARM compiler, there's an extra instruction:
push {lr}
sub sp, sp, #12
ldr r2, [sp, #0]
ldr r3, [sp, #4]
subs r3, r2, r3
cmp r3, #0
ble .L2
movs r0, #97
bl putchar(PLT)
.L2:
ldr r2, [sp, #0]
ldr r3, [sp, #4]
cmp r2, r3
ble .L3
movs r0, #98
bl putchar(PLT)
.L3:
movs r0, #0
add sp, sp, #12
pop {pc}
Note that (1) volatile is unrealistic unless you are dealing with e.g. hardware registers or thread-shared memory, and (2) that the difference in practice is not even measurable.
Because the two have different semantics in some cases, write what is correct. Worry about optimization later!
If you really like to know, in C, suppose we have test.c:
int main()
{
int a = 1000, b = 2000;
if (a > b) {
int c = 2;
}
if (a - b > 0) {
int c = 3;
}
}
Compile with gcc -S -O0 test.c, we got test.s:
.file "test.c"
.text
.globl main
.type main, #function
main:
.LFB0:
.cfi_startproc
pushq %rbp
.cfi_def_cfa_offset 16
.cfi_offset 6, -16
movq %rsp, %rbp
.cfi_def_cfa_register 6
movl $1000, -16(%rbp)
movl $2000, -12(%rbp)
movl -16(%rbp), %eax
cmpl -12(%rbp), %eax
jle .L2
movl $2, -8(%rbp)
.L2:
movl -12(%rbp), %eax
movl -16(%rbp), %edx
subl %eax, %edx
movl %edx, %eax
testl %eax, %eax
jle .L4
movl $3, -4(%rbp)
.L4:
popq %rbp
.cfi_def_cfa 7, 8
ret
.cfi_endproc
.LFE0:
.size main, .-main
.ident "GCC: (Ubuntu 4.8.2-19ubuntu1) 4.8.2"
.section .note.GNU-stack,"",#progbits
Please see the above
movl $1000, -16(%rbp)
movl $2000, -12(%rbp)
movl -16(%rbp), %eax
cmpl -12(%rbp), %eax
jle .L2
movl $2, -8(%rbp)
and
movl -12(%rbp), %eax
movl -16(%rbp), %edx
subl %eax, %edx
movl %edx, %eax
testl %eax, %eax
jle .L4
movl $3, -4(%rbp)
a - b > 0 needs one more step.
Note
The above are compiled on Ubuntu 14.04 with gcc 4.8, with optimization turned off (-O0)
As pointed out by #Blastfurnace, With -O2 or -O3, the assembly code are no longer readable. You need to profile to get a idea. But I believe they will be optimized to the same code.
Who cares
If doing the subtract and testing the sign had the same result as the comparison and ran faster, the processor designers would have mapped the integer compare instruction to a subtract and test.
I think you can assume the compare is at least as fast as subtract and test, as well as having the really major advantage of being clearer.
for readability, I always go with a > b

Resources