So my book says i can define a table of words like so:
table: dw "13,37,99,99"
and that i can snatch values from the table by incrementing the index into the address of the table like so:
mov ax, [table+2] ; should give me 37
but instead it places 0x2c33 in ax rather than 0x3337
开发者_运维知识库is this because of a difference in system architecture? maybe because the book is for 386 and i'm running 686?
0x2C is a comma ,
and 0x33 is the character 3
, and they appear at positions 2 and 3 in your string, as expected. (I'm a little confused as to what you were expecting, since you first say "should give me 37" and later say "rather than 0x3337".)
You have defined a string constant when I suspect that you didn't mean to. The following:
dw "13,37,99,99"
Will produce the following output:
Offset 00 01 02 03 04 05 06 07 08 09 0A 0B
31 33 2C 33 37 2C 39 39 2C 39 39 00
Why? Because:
- 31 is the ASCII code for '1'
- 33 is the ASCII code for '3'
- 2C is the ASCII code for ','
- ...
- 39 is the ASCII code for '9'
- NASM also null-terminates your string by putting 0 byte at the end (If you don't want your strings to be null-terminated use single quotes instead,
'13,37,99,99'
)
Take into account that ax
holds two bytes and it should be fairly clear why ax
contains 0x2C33
.
I suspect what you wanted was more along the lines of this (no quotes and we use db
to indicate we are declaring byte-sized data instead of dw
that declares word-sized data):
db 13,37,99,99
This would still give you 0x6363
(ax
holds two bytes / conversion of 99, 99 to hex). Not sure where you got 0x3337
from.
I recommend that you install yourself a hex editor and have an experiment inspecting the output from NASM.
精彩评论