• Advertisement
Sign in to follow this  

assembly help

This topic is 3953 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I seemed to have gotten the basics of asm, but now i got stuck at probably the simplest problem and I am clueless .data num1 db 1h .code mov al, num1 I supposed this would put "one" in hex so AX would be "0001" instead what I'm getting in the debugger is AX = "00FF", how is it coming up with that value? I thought maybe its a memory location of num1? Please help

Share this post


Link to post
Share on other sites
Advertisement
(I'm not sure of the assembler you're using or how the environment is set up, so this is purely speculative.)

num1 is the address of the data you're storing at num1, not the data itself. Since that data is one byte before the instruction and the assembler you're using sees num1 as a relative address, it's setting al to -1, which, two's complement in a byte, is 0xFF.

Share this post


Link to post
Share on other sites
I believe you are correct in thinking that it is indeed the memory location of num1 or at the least some other vile piece of memory. Have you tried something such as:

mov al, [num1]

Or whatever that may be in the syntax of your assembler?

Share this post


Link to post
Share on other sites
Quote:
Original post by BITWISE CHE
I believe you are correct in thinking that it is indeed the memory location of num1 or at the least some other vile piece of memory. Have you tried something such as:

mov al, [num1]

Or whatever that may be in the syntax of your assembler?


yea, I tried that, and it didnt change anything. I also did something like this
this is the whole source code:

.286
.MODEL small

.STACK 512
.DATA

;IntroMsg db "This will determine your processor type... :)$"
;WaitMsg db "Determining...$"
;OutMsg db "Your Processor is $"
;ProcType db 12 dup(?) ; max 12 chars
num1 db 1,2,3,4,5 ;// 5 bytes


.CODE
Start:
mov al, byte ptr [num1] ;// 1
mov al, byte ptr [num1+1]
mov al, byte ptr [num1+2]
mul dx

mov ah, 01h
int 21h

mov ax, 4C00h
int 21h
END Start

In the debugger

14CF : 0000 MOV AL , BYTE PTR [0004] -> AX = 0000
14CF : 0003 MOV AL , BYTE PTR [0005] -> AX = 009A
14CF : 0006 MOV AL , BYTE PTR [0006] -> AX = 00F0
14CF : 0009 MUL DX

(continues)


Note that after the first call
mov al, byte ptr [num1], AX remained zero, how is this possible?
The only thing that I found is that if subtract 000F0 - 009A and divide by
a byte (10h) you get 5, which means theres 5 bytes between the second byte and the third? Maybe this is happening because I'm not using a FLAT memory model? Any ideas?


Share this post


Link to post
Share on other sites
The data that you're loading into al is just garbage data and doesn't mean anything. The problem here is that mov al, byte ptr [foo] implies the ds segment/selector, so it's actually something like mov al, byte ptr [ds:foo]. Since your data is stored where your code is, and it looks like the addresses generated are from the start of your segment, this probably comes down to cs (code segment/selector) and ds (data segment/selector) being set to different values. Your offset is relative to cs, while you're trying to access it relative to ds.

It's been a while since I used assembly, but there may be a couple ways to solve this. The first (and most likely to work) is to simply set ds to the same thing as cs, so they point to the same data. This can be accomplished with a push cs pop ds pair (make sure you have some stack otherwise this could explode). The second method would involve prefixing your mov address with the code segment/selector, which may or may not be valid with this instruction (it's been a while). This could be accomplished with something like mov al, [cs:foo].

P.S. Depending on the type of executable you're generating (looks like a regular DOS executable), code and data addresses may be offset by a given amount (usually 0x100) to compensate for the executable header. Some assemblers implicitly account for this, while others do not. This may require an ORG 0x100 or similar statement (check your documentation) at the beginning of your file to fix the offsets. It may be the case that your cs and ds registers are fine and that this is the actual problem.

Good luck!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement