1
data segment
     S db 20 dup('$')
     T db 'true$'
     F db 'false$'
     A db 'Wabbit$'
     
     
ends

stack segment
    dw   128  dup(0)   
    pile:
    
ends

code segment
start:

    mov ax, data
    mov ds, ax
    mov es, ax
  mov dx,offset S
  mov ah,10
  int 21h
  mov cl,S[1]
  mov ch,0
  mov dx,offset S
  add dx,2 
  mov ah,9
  int 21h
    mov sp,pile
    mov si, 5 
    mov bp,sp
    
for1:    mov al,A[si]
         mov ah,0
         push ax
         dec si
         cmp si,0
         jge for1
         

  mov bp,sp
  add bp,12
  mov si,2 
  for:
      sub bp,2
      mov bx,[bp]
      mov ax,0
      mov al,S[si]
      mov ah,0
      cmp bx,ax
      jne exit
      inc si
      loop for
      mov dx , offset T
      mov ah,9
      int 21h
      jmp endd
      
 exit:
       mov dx,offset F
       mov ah,9
       int 21h
endd:
ends
end start
       
    

 
    mov ax, 4c00h ; exit to operating system.
    int 21h    
ends

end start ; set entry point and stop the assembler.

That is my code.

This is the question:

Write an 8086 assembly program that takes from the user a string S of size 20 and determines whether the content of S is found on the top of a given stack of words (2 bytes) already defined and filled with the values shown below:
Example: let S1="Wabbit" entered by the user and the content of the stack is given above, the program will display "True" and S2="Exam", the program will display "False". Remember the content of stack is fixed always "Wabbit", however the content of S changes.

Also I have 'false', why?

I try to know the problem by running step by step so when I do pop first I have 74h the value of "W" but when I put the value of "W" from the string S it gives 57h. Why?

Sep Roland
  • 33,889
  • 7
  • 43
  • 76
  • It's unclear why you need a stack or what exactly you are doing, but note that you iterate the stack in the same order as you have put the items in so not as a stack. Thus the first character you get from there will be the `t` which is the `57` (hex). Also the `loop` instruction will need a counter in `cx`. – Jester Jul 20 '23 at 12:25

2 Answers2

1
S db 20 dup('$')
T db 'true$'
F db 'false$'

The definition for the S buffer is wrong. It is an open invitation for buffer overflow and memory corruption. The first byte, that should inform DOS about the length of the buffer, is 36 here (ASCII for '$'). So DOS can and will overwrite (parts of) those 'true' and 'false' messages for the buffer memory!

Learn to use the DOS.BufferedInput function 0Ah correctly. Read all about it in How buffered input works.


mov dx,offset S
add dx,2 
mov ah,9

The DOS.PrintString function 09h expects to receive a $-terminated string. You think you've done that by pre-loading the buffer with $ characters. There's no guarantee whatsoever that those $ characters are still there once the function 0Ah returned. You should always put a $ character explicitly. Again, read about it in How buffered input works.


  mov bp,sp        <<<< first time
for1:
  mov al,A[si]
  mov ah,0
  push ax
  dec si
  cmp si,0
  jge for1
  mov bp,sp        <<<< second time
  add bp,12        <<<<  same value in BP

The for1 loop correctly pushes the A string that contains the text "Wabbit" on the stack, but why do you setup the BP register twice? You could simply omit those mov bp, sp add bp, 12 lines at the bottom, but better also remove the mov bp, sp line at the top because that's the root cause why the program malfunctions.

You are comparing two strings but starting at the first character for the inputted string and starting at the last character for the stacked string. The starting points need to correspond.

And because I see no good reason to first push the "Wabbit" string on the stack, only to traverse it like a regular string in memory (such as it was defined at A), I suggest you pop the characters for the purpose of comparing:

  mov  dx, offset F
  mov  cl, S[1]       ; 1
  mov  ch, 0          ; 1
  cmp  cx, 6          ; 2
  jne  exit           ; 2
  mov  si, 2          ; We have same number of characters at SI as at SP
for:
  pop  ax
  cmp  al, S[si]
  jne  exit
  inc  si
  loop for            ; 1
  mov  dx , offset T
exit:
  mov  ah, 09h
  int  21h
  mov  ax, 4C00h
  int  21h
  1. The loop instruction depends on the CX register. Don't forget to initialize it beforehand.
  2. And because you will be comparing against a fixed string with a known length of 6 characters, it will make sense to return 'false' if the length of the inputted string is anything other than 6.

endd:
ends
end start
  mov ax, 4c00h ; exit to operating system.
  int 21h    
ends
end start

You should not duplicate those ends and end start lines!

Sep Roland
  • 33,889
  • 7
  • 43
  • 76
-2

Looking at your code, I can see a few logic errors. The most important thing to understand is that x86's stack must be accessed two bytes at a time when using push or pop. There is no push al, you have to use push ax, for example. You seem to understand that, which is why you have used mov ah,0 as padding.

However, the end user isn't able to put this padding into the string they type. So even if you type "Wabbit" at the beginning of the program, your program is trying to compare db "Wabbit" with db "W",0,"a",0,"b",0,"b",0,"i",0,"t",0 which is why you're getting "false" as the answer. In order to properly compare the two you'd need to convert the input string to a similar padded form that your test string "Wabbit" is stored on the stack.

(Side note: The example I gave earlier db "W",0,"a",0,"b",0,"b",0,"i",0,"t",0 might actually be db 0,"W",0,"a",0,"b",0,"b",0,"i",0,"t", I can't remember off the top of my head which order al and ah go on the stack when you push ax. If one doesn't work try the other.)

puppydrum64
  • 1,598
  • 2
  • 15
  • 2
    The user's input is in `S` and is in fact correctly byte addressed and converted to word via `mov al,S[si]; mov ah,0` – Jester Jul 20 '23 at 13:53
  • Ah, must have missed that. My mistake. There are a few other logic errors I noticed, I'll run this through a hex dump program later and see if I can correct my answer with the actual problem. – puppydrum64 Jul 20 '23 at 14:03