I am currently studying microprocessors specifically the 8086 and was just recently introduced to assembly level language. I am currently stuck at the assembly level program for nCr(combination) through the recursive procedure for which the assembly level code is given below, can somebody please explain what's the logic used here, in calculating nCr through recursion.
I don't want the explanation of the whole program but I just want a basic idea about the working of recursion for nCr which I am not able to understand.
I have solved this problem of nCr through recursion(not in assembly language as I have started learning assembly recently) but with a different type of logic, that is by implementing the factorial function recursively and then calculating the nCr by using the formula of nCr, but some other logic is used here, which I am not able to understand.
This code was posted as an example on 8086{4}beginner.com, with no comments.
DATA SEGMENT
n db 10
r db 9
ncr db 0
DATA ENDS
code segment
assume cs:code,ds:data
start: mov ax,data
mov ds,ax
mov ncr,0
mov al,n
mov bl,r
call encr
call display
mov ah,4ch
int 21h
encr proc
cmp al,bl
je ncr1
cmp bl,0
je ncr1
cmp bl,1
je ncrn
dec al
cmp bl,al
je ncrn1
push ax
push bx
call encr
pop bx
pop ax
dec bl
push ax
push bx
call encr
pop bx
pop ax
ret
ncr1: inc ncr
ret
ncrn1: inc al
ncrn: add ncr,al
ret
encr endp
display proc
push cx
mov al,ncr
mov ch,al
and al,0f0h
mov cl,04
shr al,cl
cmp al,09h
jbe next
add al,07h
next:add al,30h
mov dl,al
mov ah,02h
int 21h
mov al,ch
and al,0fh
cmp al,09h
jbe next2
add al,07h
next2:add al,30h
mov dl,al
mov ah,02h
int 21h
pop cx
ret
display endp
code ends
end start
I don't want explanation for whole of the assembly code, I am just stuck at the logic behind recursion that is, I am not able to understand what logic is used for calculation of nCr. For example I know that if base cases don't match value of al is decreased until it matches one of the base cases (value of bl is also decreased by one as the program proceeds), and the calculation of nCr is done by either incrementing it by one or by adding al to it as per the base cases.
I am not able to understand how just some addition work can calculate nCr that is I am not able to understand logic behind recursion.
Related
I'm trying to make the Factorial procedure but it's not working for some reason.
I'm sorry, but I have literally no idea what the problem is. I tried debugging with gdb but I couldn't figure it out.
push 4
call Factorial
exit
Factorial:
cmp byte [rsp + 8], 0
jz end
mov eax, [rsp + 8]
mov ebx, eax
dec ebx
imul eax, ebx
add rsp, 8
push rbx
call Factorial
end:
ret
The problem is in the calling convention of procedure Factorial.
Recursive procedures are better called with input/output in registers instead of pushed on stack.
I used your algorithm for 32bit Windows and debugged in OllyDbg, but it shouldn't be difficult to modify it for 64bit Linux.
user259137 PROGRAM Format=PE,Width=32,Entry=Start
IMPORT ExitProcess,Lib=kernel32.dll
Start:
MOV EAX,4
CALL Factorial ; Returns factorial of EAX in EAX.
PUSH EAX ; Errorlevel to exit with.
JMP ExitProcess
Factorial: ; Returns factorial of EAX in EAX.
CMP EAX,1
JNA end
PUSH EBX ; Do not clobber any reg but EAX.
MOV EBX,EAX
DEC EAX
CALL Factorial
IMUL EAX,EBX
POP EBX
end:RET
ENDPROGRAM
Created with euroasm.exe user259137.asm.
Factorial can also be computed recursively at assembly time at macro-level, see this example.
I am trying to wrap my mind around pointers in Assembly.
What exactly is the difference between:
mov eax, ebx
and
mov [eax], ebx
and when should dword ptr [eax] should be used?
Also when I try to do mov eax, [ebx] I get a compile error, why is this?
As has already been stated, wrapping brackets around an operand means that that operand is to be dereferenced, as if it were a pointer in C. In other words, the brackets mean that you are reading a value from (or storing a value into) that memory location, rather than reading that value directly.
So, this:
mov eax, ebx
simply copies the value in ebx into eax. In a pseudo-C notation, this would be: eax = ebx.
Whereas this:
mov eax, [ebx]
dereferences the contents of ebx and stores the pointed-to value in eax. In a pseudo-C notation, this would be: eax = *ebx.
Finally, this:
mov [eax], ebx
stores the value in ebx into the memory location pointed to by eax. Again, in pseudo-C notation: *eax = ebx.
The registers here could also be replaced with memory operands, such as symbolic variable names. So this:
mov eax, [myVar]
dereferences the address of the variable myVar and stores the contents of that variable in eax, like eax = myVar.
By contrast, this:
mov eax, myVar
stores the address of the variable myVar into eax, like eax = &myVar.
At least, that's how most assemblers work. Microsoft's assembler (called MASM), and the Microsoft C/C++ compiler's inline assembly, is a bit different. It treats the above two instructions as equivalent, essentially ignoring the brackets around memory operands.
To get the address of a variable in MASM, you would use the OFFSET keyword:
mov eax, OFFSET myVar
However, even though MASM has this forgiving syntax and allows you to be sloppy, you shouldn't. Always include the brackets when you want to dereference a variable and get its actual value. You will never get the wrong result if you write the code explicitly using the proper syntax, and it'll make it easier for others to understand. Plus, it'll force you to get into the habit of writing the code the way that other assemblers will expect it to be written, rather than relying on MASM's "do what I mean, not what I write" crutch.
Speaking of that "do what I mean, not what I write" crutch, MASM also generally allows you to get away with omitting the operand-size specifier, since it knows the size of the variable. But again, I recommend writing it for clarity and consistency. Therefore, if myVar is an int, you would do:
mov eax, DWORD PTR [myVar] ; eax = myVar
or
mov DWORD PTR [myVar], eax ; myVar = eax
This notation is necessary in other assemblers like NASM that are not strongly-typed and don't remember that myVar is a DWORD-sized memory location.
You don't need this at all when dereferencing register operands, since the name of the register indicates its size. al and ah are always BYTE-sized, ax is always WORD-sized, eax is always DWORD-sized, and rax is always QWORD-sized. But it doesn't hurt to include it anyway, if you like, for consistency with the way you notate memory operands.
Also when I try to do mov eax, [ebx] I get a compile error, why is this?
Um…you shouldn't. This assembles fine for me in MSVC's inline assembly. As we have already seen, it is equivalent to:
mov eax, DWORD PTR [ebx]
and means that the memory location pointed to by ebx will be dereferenced and that DWORD-sized value will be loaded into eax.
why I cant do mov a, [eax] Should that not make "a" a pointer to wherever eax is pointing?
No. This combination of operands is not allowed. As you can see from the documentation for the MOV instruction, there are essentially five possibilities (ignoring alternate encodings and segments):
mov register, register ; copy one register to another
mov register, memory ; load value from memory into register
mov memory, register ; store value from register into memory
mov register, immediate ; move immediate value (constant) into register
mov memory, immediate ; store immediate value (constant) in memory
Notice that there is no mov memory, memory, which is what you were trying.
However, you can make a point to what eax is pointing to by simply coding:
mov DWORD PTR [a], eax
Now a and eax have the same value. If eax was a pointer, then a is now a pointer to that same memory location.
If you want to set a to the value that eax is pointing to, then you will need to do:
mov eax, DWORD PTR [eax] ; eax = *eax
mov DWORD PTR [a], eax ; a = eax
Of course, this clobbers the pointer and replaces it with the dereferenced value. If you don't want to lose the pointer, then you will have to use a second "scratch" register; something like:
mov edx, DWORD PTR [eax] ; edx = *eax
mov DWORD PTR [a], edx ; a = edx
I realize this is all somewhat confusing. The mov instruction is overloaded with a large number of potential meanings in the x86 ISA. This is due to x86's roots as a CISC architecture. By contrast, modern RISC architectures do a better job of separating register-register moves, memory loads, and memory stores. x86 crams them all into a single mov instruction. It's too late to go back and fix it now; you just have to get comfortable with the syntax, and sometimes it takes a second glance.
I have a few issues with using registers and storing data.
Before I read in a character I want a buffer of size 100 that the register ESI points to.
Do I use this?
mov esi, 100 to store a buffer for size 100,
and then
mov esi, [al]
inc esi
to store the current character I entered into the esi and move it to the next location to store a new character?
I also can't find out how to properly check if a null terminated character is entered.
I've tried cmp al, 0xa to check for a new line
and cmp eax, -1 to check eof.
Note: I have a function called read_char to read in a character to put into the al register
To define a buffer in NASM you can use buffer times 100 db 0
You get its address with mov esi, buffer
To store the character in AL in it, and raise the address write mov [esi], al inc esi
how to properly check if a null terminated character is entered
The null would be the byte following the character. You need to compare a word for that. Read the character and the following byte, then compare:
mov ax, [esi]
cmp ax, 0x000A
This tests if linefeed was the last item in this zero-terminated string.
int sort(int* list)
{
__asm
{
mov esi, [list];
mov eax, dword ptr[esi + edx * 4]; store pointer to eax?
mov edi, dword ptr[esi + 4 + edx * 4]; store pointer to edi?
jmp swap;
swap:
push dword ptr[esi + edx * 4];
mov dword ptr[esi + edx * 4], edi;
pop dword ptr[esi + 4 + edx * 4];
This is a portion of my homework code, it works properly but I want to know how I can change my swap to use registers instead of dword ptrs. I initially had:
swap: (none of this works... values remain unchanged. why? =[ )
push eax; supposed to push value pointed to?
mov eax, edi; supposed to change value pointed at by eax?
pop edi; supposed to pop pushed value into edi pointer location?
but this doesn't actually swap anything, the array passed in doesn't change. How can I get rewrite my code so that the swap statement looks like this? I tried putting [] around eax in the above swap statement but that doesn't work either.
With three instructions (as Kerrek SB said) and only one register (EAX):
int exchange ()
{ int list[5] = {1,5,2,4,3};
__asm { mov edx, 0
lea esi, list
// SWAP WITH THREE INSTRUCTIONS.
mov eax, [esi + edx * 4]
xchg [esi + 4 + edx * 4], eax
mov [esi + edx * 4], eax
// NOW LIST = {5,1,2,4,3};
}
}
Or, with the array as parameter :
int exchange ( int * list )
{ __asm { mov edx, 0
mov esi, list
// SWAP WITH THREE INSTRUCTIONS.
mov eax, [esi + edx * 4]
xchg [esi + 4 + edx * 4], eax
mov [esi + edx * 4], eax
// LIST = {5,1,2,4,3};
}
}
And this is how to call it :
int list[5] = {1,5,2,4,3};
exchange( list );
From what I understand you want to swap two double word values within two different arrays and you want to do this using two registers. You are loading EAXand EDI with two values (one from each array), after you swap the register values you need to store/save them back into their respective array offsets in memory for their values to change. So continuing your line of code, try:
Push Eax
Mov Eax, Edi
Pop Edi
Mov dword ptr[esi + 4 + edx * 4], Eax
Mov dword ptr[esi + edx * 4], Edi
You can leave out the dword ptr type override prefix when the destination operand is an extended register, I believe it will be assumed that the source value will be the same size (double word). So this will also work:
mov eax, [esi + edx * 4]
mov edi, [esi + 4 + edx * 4]
Also, do you have to use that mode of addressing? It seems you are using indirect indexed displacement addressing.
Part of the confusion might be how your function receives its inputs. If you write your whole function in asm, rather than inline with MSVC-specific syntax, then the ABI tells you that your parameters will be on the stack (for 32bit x86 code). http://www.agner.org/optimize/ has a calling-conventions doc, too, covering the various different calling conventions for x86 and x86-64.
Anyway.
xchg might seem like exactly the instruction you want for doing a swap. If you really do need to exchange the contents of two registers, it's very similar in performance to the 3 mov instructions that would otherwise be required, but without the temporary register needed. However, it's somewhat rare to actually need to swap two registers, rather than just overwrite one, or save the old value somewhere else. Also, 3 mov reg, reg will be faster on Ivy Bridge / Haswell, because they don't need an execution unit for it; they just handle it in the register rename stage (with 0 latency).
For swapping the contents of two memory locations, it's at least 25 times slower than using mov for loads/stores, due to the implicit LOCK prefix forcing the CPU to make sure all other cores get the update right away, instead of just writing to L1 cache.
What you need to do is 2 loads, and 2 stores.
The simplest form (2 loads, 2 stores, works in the general case) will be
# void swap34(int *array)
swap34:
# 32bit: mov edi, [esp+4] # [esp] has the return address
# 64bit windows: mov rdi, rcx # first function arg comes in rcx
# array pointer in rdi, assuming 64bit SystemV (Linux) ABI.
mov eax, [rdi+8] # load array[3]
mov ebx, [rdi+12] # load array[4]
mov [rdi+12], eax # store array[4] = tmp1
mov [rdi+8], ebx # store array[3] = tmp2
ret
With more complex addressing modes (e.g. [rdi+rax*4], you could swap list[rax] with list[rbx].)
If the memory locations are adjacent, and you can load both at once with a wider load, and rotate to swap. e.g.
# int *array in rdi
mov rax, [rdi+4] # load 2nd and 3rd 32bit element
rol rax, 32 # rotate left by half the reg width
mov [rdi+4], rax # store back to the same place
I believe those 3 instructions will actually run faster than rol [rdi+4], 32. (rotate with memory operand and imm8 count is 4 uops on Intel Sandybridge, throughput of 1 per 2 cycles. The load/rot/store is 3 uops, and should sustain 1 per cycle. The memory-operand version uses fewer instruction bytes. It doesn't leave either value in a register, though. Usually in real code, you're going to want to do something further with one of the values.)
The only other way I can think of to use fewer instructions would if you had rsi and rdi pointing at the values to be swapped. Then you could
movd eax, [rdi] ; DON'T DO THIS,
movsd ; string-move, 4B version. copies [rsi] to [rdi]
movd [rsi-4], eax ; IT'S SLOW
This would be a lot slower than 2 loads / 2 stores, and movsd increments rsi and rdi. Saving an instruction here actually makes for slower code, and code that uses MORE space in the uop cache on recent Intel design. (A movsd without a rep prefix is never a good choice.)
Another instruction that reads from one memory location and writes to another is pop or push with a memory operand, but that only works if the stack pointer was already pointing to one of the values you wanted to swap, and you didn't care about changing the stack pointer.
Don't go messing with the stack pointer. You can in theory save the stack pointer somewhere, and use it as another GP register for a loop where you're out of registers, but only if you don't need to call anything, and nothing asynchronous can happen that might try to use the stack while you have rsp not pointing at the stack. Seriously, it's really rare for even hand-written performance-tuned asm to use the stack pointer for anything but the normal use, so really just forget I mentioned it.
I am trying to figure out how register indirect addressing works. I have a variable that stores the value of 5 as follows:
section .data
number db 53 ; ascii code for 5
section .bss
number2 resb 1
section .text
global _start
_start:
mov eax,number
mov number2,[eax]
At the last two lines of the code what I am essentially trying to do is made eax act like a pointer to the data stored at number and then move this data into the number2 variable. I had though indirect register addressing was done via [register] but my code does not seem to work. Any help with regards to syntax would be much appreciated.
Labels work as addresses in nasm so your mov number2, [eax] would translate to something like mov 0x12345678, [eax] which is of course invalid because you cannot move data to immediate operand. So you would need mov [number2], [eax] but that's also invalid.
You can achieve this using some register to temporarily hold the value [eax]:
mov eax, number
mov dl, [eax]
mov [number2], dl
The problem here is, that number and number2 are not numbers, i.e. immediate literals. Instead they are interpreted as absolute memory addresses and the corresponding instructions, if they would exist would be e.g.
mov eax, [0x80000100] ;; vs
mov [0x80000104], [eax] ;; Invalid instruction
One has to pay attention to the instruction format as well, as answered by Mika Lammi -- is the instruction
mov src, dst ;; vs
mov dst, src
In addition, one should match the register size to the variable size; i.e
.data
number db 1; // this is a byte
.code
mov al, number