开发者

Addressing memory data in 32 bit protected mode with nasm

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.

0

上一篇:

下一篇:

精彩评论

暂无评论...
验证码 换一张
取 消

最新问答

问答排行榜