My program prints the msg3 statement (PutStr msg3), but does not proceed to the
DIV CX
instruction in my program.
Is there something I'm doing incorrectly with that register?
Or should the instruction be
DIV [CX]
instead or do I not have the compare and jump conditions set correctly?
prime_loop:
sub AX,AX ;clears the reg to allow the next index of the array
sub CX,CX ;clears counter to decrement starting from number of the value for array
mov AX, [test_marks+ESI*4] ;copy value of array at index ESI into reg
mov CX, [test_marks+ESI*4] ;copy value of array at index ESI into reg for purposes of counting down
check_prime:
dec CX
nwln
PutStr msg3
div WORD CX ;divide value of EAX by ECX
cmp DX,0 ;IF the remainder is zero
je chck_divisor ;check to see divisor 'ECX'
sub AX,AX ;else clear quotient register EAX
sub DX,DX ;clear remainder register
mov AX,[test_marks+ESI*4] ;move the number of the current iteration back into EAX
jmp check_prime ;start again from loop
chck_divisor:
cmp CX,1
jne prime_loop ;if the divisor is not 1 then it is not a prime number so continue with iterations
PutInt AX ;else print the prime_num
PutStr
inc ESI
jmp prime_loop
done:
.EXIT
These are some points about your code:
If this is indeed 8086 assembly then instructions like mov AX, [test_marks+ESI*4] that use scaled indexed addressing simply don't exist!
The scale by 4 suggests that your array is filled with doublewords, yet you use just a word. This could be what you want, but it looks suspicious.
Let's hope no array element is 1 because if so, then the div cx instruction will trigger an exception (#DE). Because you don't test the CX register for becoming 0.
In the check_prime loop only the 1st iteration lacks the zeroing of DX in order to give a correct quotient.
The solution will depend on the targetted architecture 8086 or x86. Now your program is a mix of both!
It's possible that since DX is not zeroed before div, that you're getting overflow. I don't know how your environment handles overflow.
Related
I'm was working on some homework to print out an array as it's sorting some integers from an array. I have the code working fine, but decided to try using EAX instead of AL in my code and ran into errors. I can't figure out why that is. Is it possible to use EAX here at all?
; This program sorts an array of signed integers, using
; the Bubble sort algorithm. It invokes a procedure to
; print the elements of the array before, the bubble sort,
; once during each iteration of the loop, and once at the end.
INCLUDE Irvine32.inc
.data
myArray BYTE 5, 1, 4, 2, 8
;myArray DWORD 5, 1, 4, 2, 8
currentArray BYTE 'This is the value of array: ' ,0
startArray BYTE 'Starting array. ' ,0
finalArray BYTE 'Final array. ' ,0
space BYTE ' ',0 ; BYTE
.code
main PROC
MOV EAX,0 ; clearing registers, moving 0 into each, and initialize
MOV EBX,0 ; clearing registers, moving 0 into each, and initialize
MOV ECX,0 ; clearing registers, moving 0 into each, and initialize
MOV EDX,0 ; clearing registers, moving 0 into each, and initialize
PUSH EDX ; preserves the original edx register value for future writeString call
MOV EDX, OFFSET startArray ; load EDX with address of variable
CALL writeString ; print string
POP EDX ; return edx to previous stack
MOV ECX, lengthOf myArray ; load ECX with # of elements of array
DEC ECX ; decrement count by 1
L1:
PUSH ECX ; save outer loop count
MOV ESI, OFFSET myArray ; point to first value
L2:
MOV AL,[ESI] ; get array value
CMP [ESI+1], AL ; compare a pair of values
JGE L3 ; if [esi] <= [edi], don't exch
XCHG AL, [ESI+1] ; exchange the pair
MOV [ESI], AL
CALL printArray ; call printArray function
CALL crlf
L3:
INC ESI ; increment esi to the next value
LOOP L2 ; inner loop
POP ECX ; retrieve outer loop count
LOOP L1 ; else repeat outer loop
PUSH EDX ; preserves the original edx register value for future writeString call
MOV EDX, OFFSET finalArray ; load EDX with address of variable
CALL writeString ; print string
POP EDX ; return edx to previous stack
CALL printArray
L4 : ret
exit
main ENDP
printArray PROC uses ESI ECX
;myArray loop
MOV ESI, OFFSET myArray ; address of myArray
MOV ECX, LENGTHOF myArray ; loop counter (5 values within array)
PUSH EDX ; preserves the original edx register value for future writeString call
MOV EDX, OFFSET currentArray ; load EDX with address of variable
CALL writeString ; print string
POP EDX ; return edx to previous stack
L5 :
MOV AL, [ESI] ; add an integer into eax from array
CALL writeInt
PUSH EDX ; preserves the original edx register value for future writeString call
MOV EDX, OFFSET space
CALL writeString
POP EDX ; restores the original edx register value
ADD ESI, TYPE myArray ; point to next integer
LOOP L5 ; repeat until ECX = 0
CALL crlf
RET
printArray ENDP
END main
END printArray
; output:
;Starting array. This is the value of array: +1 +5 +4 +2 +8
;This is the value of array: +1 +4 +5 +2 +8
;This is the value of array: +1 +4 +2 +5 +8
;This is the value of array: +1 +2 +4 +5 +8
;Final array. This is the value of array: +1 +2 +4 +5 +8
As you can see the output sorts the array just fine from least to greatest. I was trying to see if I could move AL into EAX, but that gave me a bunch of errors. Is there a work around for this so I can use a 32 bit register and get the same output?
Using EAX is definitely possible, in fact you already are. You asked "I was trying to see if I could move AL into EAX, but that gave me a bunch of errors." Think about what that means. EAX is the extended AX register, and AL is the lower partition of AX. Take a look at this diagram:image of EAX register
. As you can see, moving AL into EAX using perhaps the MOVZX instruction would simply put the value in AL into EAX and fill zeroes in from right to left. You'd be moving AL into AL, and setting the rest of EAX to 0. You could actually move everything into EAX and run the program just the same and there'd be no difference because it's using the same part of memory.
Also, why are you pushing and popping EAX so much? The only reason to push/pop things from the runtime stack is to recover them later, but you never do that, so you can just let whatever is in EAX at the time just die.
If you still want to do an 8-bit store, you need to use an 8-bit register. (AL is an 8-bit register. IDK why you mention 16 in the title).
x86 has widening loads (movzx and movsx), but integer stores from a register operand always take a register the same width as the memory operand. i.e. the way to store the low byte of EAX is with mov [esi], al.
In printArray, you should use movzx eax, byte ptr [esi] to zero-extend into EAX. (Or movsx to sign-extend, if you want to treat your numbers as int8_t instead of uint8_t.) This avoids needing the upper 24 bits of EAX to be zeroed.
BTW, your code has a lot of unnecessary instructions. e.g.
MOV EAX,0 ; clearing registers, moving 0 into each, and initialize
totally pointless. You don't need to "init" or "declare" a register before using it for the first time, if your first usage is write-only. What you do with EDX is amusing:
MOV EDX,0 ; clearing registers, moving 0 into each, and initialize
PUSH EDX ; preserves the original edx register value for future writeString call
MOV EDX, OFFSET startArray ; load EDX with address of variable
CALL writeString ; print string
POP EDX ; return edx to previous stack
"Caller-saved" registers only have to be saved if you actually want the old value. I prefer the terms "call-preserved" and "call-clobbered". If writeString destroys its input register, then EDX holds an unknown value after the function returns, but that's fine. You didn't need the value anyway. (Actually I think Irvine32 functions at most destroy EAX.)
In this case, the previous instruction only zeroed the register (inefficiently). That whole block could be:
MOV EDX, OFFSET startArray ; load EDX with address of variable
CALL writeString ; print string
xor edx,edx ; edx = 0
Actually you should omit the xor-zeroing too, because you don't need it to be zeroed. You're not using it as counter in a loop or anything, all the other uses are write-only.
Also note that XCHG with memory has an implicit lock prefix, so it does the read-modify-write atomically (making it much slower than separate mov instructions to load and store).
You could load a pair of bytes using movzx eax, word ptr [esi] and use a branch to decide whether to rol ax, 8 to swap them or not. But store-forwarding stalls from byte stores forwarding to word loads isn't great either.
Anyway, this is getting way off topic from the title question, and this isn't codereview.SE.
This question already has an answer here:
Problems with IDIV Assembly Language
(1 answer)
Closed 1 year ago.
The pseudocode is the following:
read c //a double digit number
for(i=1,n,i++)
{ if (n%i==0)
print i;}
In assembly I have written it as:
mov bx,ax ; ax was the number ex.0020, storing a copy in bx.
mov cx,1 ; the start of the for loop
.forloop:
mov ax,bx ; resetting ax to be the number(needed for the next iterations)
div cx
cmp ah,0 ; checking if the remainder is 0
jne .ifinstr
add cl 48 ;adding so my number would be displayed later as decimal
mov dl,cl ;printing the remainder
mov ah,2
int 21h
sub cl,48 ;converting it back to hexa
.ifinstr:
inc cx ;the loop goes on
cmp cx,bx
jle .forloop
I've checked by tracing its steps. The first iteration goes well, then, at the second one, it makes ax=the initial number and cx=2 as it should, but at 'div cx' it jumps somwhere unknown to me and it doesn't stop anywhere. It does:
push ax
mov al,12
nop
push 9
.
.
Any idea why it does that?
try to do mov dx,0 just before div instruction.
Basically every time you come after jump, there may be some data in dx register, so you can just move zero in dx or XOR dx,dx.
This is to be done, because otherwise division will be considered differently.
See this:
Unsigned divide.
Algorithm:
when operand is a byte:
AL = AX / operand
AH = remainder (modulus)
when operand is a word:
AX = (DX AX) / operand
DX = remainder (modulus)
Example:
MOV AX, 203 ; AX = 00CBh
MOV BL, 4
DIV BL ; AL = 50 (32h), AH = 3
RET
I am experiencing some difficulties with understanding of how I can calculate the offset to the row in two dimensional array. The offsets will be used by main later to access the rows for the assignments and quizzes.
Assuming that I have,
scores DWORD 80,80,100, ; midterms, 2 scores
20,20,20,20,20,20,20,100, ; assignments, 7 scores
10,10,10,10,10,10,100 ; quizzes, 6 scores (lowest score dropped)
where "100" is a sentinel value. I understand that the offset is how many bytes away is the row from the start of array.
mov ecx, sentinelVal
mov edi, OFFSET scores
mov eax, sentinelVal
OffsetLoop:
repne scasd ; walk through the array until the target value is found.
jnz endLoop ; if the sentinel value is not found jump from the loop
; If the sentinel value if found
; edi is pointing to the location after the sentinel value
; I am not sure what I should do with the address of the array and edi
; to figure out the offset. Any help would be appreciated. Thanks!
loop OffsetLoop
endLoop:
edited:
I figured out what was my problem. My approach to calculate the offset was right, but it was the loop that caused the problem. It's not possible to simply set ecx to any arbitrary large numbers because scasd also uses ecx as a counter. By setting ecx to a large number, the instruction goes beyond the array boundary which triggers the exception.
mov ecx, LENGTHOF scores
OffsetLoop:
cld
repne scasd
jnz endLoop
mov ebx, edi
sub ebx, OFFSET scores
push ebx
inc ecx
loop OffsetLoop
endLoop:
Assuming your descriptions are correct in that edi is left pointing one beyond the sentinel word, you can simply do:
sub edi, OFFSET scores
to get the byte offset from the beginning of the table.
I'd be a little worried about this though:
mov ecx, sentinelVal
The ecx register is supposed to be a length limit and, while 100 may be a decent value, you should have a different symbolic name for it such as lenLimit.
I am trying to make a for loop in assembly where the EAX register is set to 5, and increased until it is greater than 10. Each time it increases, it outputs it's current value. When I execute my program, it goes in an infinite loop which only outputs 4. Why is EAX's value 4? Why is register EAX not increasing as it should?
include 'include/macro/import32.inc'
format PE console
entry start
section '.text' code readable executable
start:
mov eax,5
loop1:
inc eax
push eax
push msg2
call [printf]
cmp eax,10
jb loop1
call [getchar]
push 0
call [exit]
section '.data' data readable writable
msg2 db "%i",0dh,0ah,0
section 'idata' import data readable
library msvcrt,"msvcrt.dll"
import msvcrt,printf,"printf",getchar,"getchar",exit,"exit"
The output from printf is returned in eax which contains the number of characters printed: 3 in your case (the digit, CR, and LF). Since that is less than 10, you loop up, add 1 (which makes it 4), print that, and repeat.
What you need to do is store eax (push eax) before setting up the printf call, then restore it (pop eax) after printf returns like:
loop1:
inc eax
push eax ; store eax
push eax
push msg2
call [printf]
add esp,8 ; clean the stack from the printf call
pop eax ; restore eax
cmp eax,10
jb loop1
Or use a different register such as ebx for your loop variable.
Always preserve EAX before using printf. printf destroys your EAX
inc eax
push eax
...call to printf
pop eax
cmp eax,10
Question:
Write a procedure that performs simple encryption by rotating each plaintext byte a varying
number of positions in different directions. For example, in the following array that represents
the encryption key, a negative value indicates a rotation to the left and a positive value indicates
a rotation to the right. The integer in each position indicates the magnitude of the rotation:
key BYTE -2, 4, 1, 0, -3, 5, 2, -4, -4, 6
Code:
Include Irvine32.inc
.data
msg BYTE "Hello", 0
key BYTE -2, 4, 1, 0, -3, 5, 2, -4, -4, 6
.code
main proc
mov ecx, LENGTHOF key ;Loop Counter
mov edx, OFFSET msg ;EDX Holds msg and will Display it
mov esi, OFFSET key ;Point to first array element
mov ebx, 0 ;CMP number
top:
cmp [esi], ebx ;if esi < ebx
jl ShiftLeft ;jump to shift left
cmp [esi], ebx ;if esi > ebx
jg ShiftRight ;jump to shift right
cmp [esi], ebx
je NoShift
ShiftLeft:
mov cl, [esi]
SHL edx, cl
add esi, TYPE key
loop top
ShiftRight:
mov cl, [esi]
SHR edx, cl
add esi, TYPE key
loop top
NoShift:
add esi, TYPE key
loop top
call WriteString
invoke ExitProcess,0
main endp
end main
So I am having a few issues.
1.the cmp statements are going in reverse. So the first cmp should be cmping -2 and 0. -2 < 0, So it should be taking the jump and going to Shiftleft. However, it is doing the opposite and going to shiftright.
2. Am I incrementing to the next array index properly with the add esi, TYPE key line?
3. Am I understanding the question? I need to rotate my msg, "Hello", either left if the number in the array is negative, by that number, and to the right if the number is positive in the array.
Any help is great and thanks in advance.
In your comparison
cmp [esi], ebx
this does not compare [esi] with ebx. It compares ebx with [esi] which is why you think the branch decision is incorrect. As a point of technique, you don't need to test all three conditions, since the last one must be true.
cmp [esi], ebx
je NoShift
jl ShiftRight ;else fall thru to ShiftLeft
You are correctly moving the pointer to the next array position with
add esi, TYPE key
but you have forgotten to increment the message pointer edx.
I presume that you would encode the character by rotating the byte, not shifting it, and you mistakenly rotate the pointer instead of its target
mov cl, [esi]
rol BYTE PTR [edx], cl
There is another problem - you are using cx for the loop control, but you are overwriting cl (the l.s. 8 bits of cx) with the bit shift counter. I'll leave you to figure out how to get around that.
I didn't run you code so may analysis may be wrong.
The cmp [esi], ebx do compare [esi] with ebx of course (it is just a [esi]-ebx). The mistake here is that you are comparing DWORDs instead of byte. As a rule of thumb, always specify memory operand size: cmp BYTE PTR [esi], bl this way the assembler can tell you if you are doing wrong.
You made other mistakes as pointed out by #WeatherVan.
I'd like to add that you don't need to do any jump due to the way two complement works and the symmetry of rotations. Remember: jump is expensive arithmetic is not.
If you take the low 3 bit (since you are rotating 8 bit data and 2^3=8) of the key bytes, you can always rotate to the right. A rotation of, say, 2 on the left is a rotation of 6 on the right and 6 is the two complement of 2 in 3 bits.
I also think that you need to repeat the key on the message, i.e. if the message is longer than the key you need to reload it from the start.
Here a sample program in NASM that you can use to better understand my advices
BITS 32
GLOBAL _main
SECTION .data
msg db "Hello ",0
key db -2, 4, 1, 0, -3, 5, 2, -4, -4, 6
SECTION .text
_main:
mov esi, msg
.load_key:
mov ebx, 10 ;LENGTHOF key
mov edi, key
.loop:
mov cl, BYTE [edi] ;Key
lodsb ;Char of message
test al, al ;End of string?
jz .end
and cl, 07h ;We are working with 8 bit numbers, 3bits of operand are enough
ror al, cl ;Rotate
mov BYTE [esi-01h], al
inc edi ;Next char
dec ebx ;Key left
jnz .loop
jmp .load_key
.end:
ret