5.3那节将ffff：0006中的数乘以3，然后存入dx。我发现了点下问题。。。

疏疏里

下面是该题的一种不正确的代码。。。
assume cs:code
code segment
mov ax,0ffffH
mov ds,ax
mov ax,ds:6H
mov cx,3
s:add dx,ax
loop s
mov ax,4c00H
int 21H
code ends
end

-----------------------------------------
上面这段代码，其中

mov ax,ds:6H
这一句的问题，它本身应该没问题，它通过了编译而且还能执行，可我觉得放在这里就错了。

我们可以查到ffff：0006这个内存空间存的数是多少的。我们都知道实验一后面的一个查主板ROM生产日期的经典问题。
如果还有印象的话，我们就会发现ffff：0006中存放的是生产日期中的月份，的个位。比如我的是09月，（09/25/10为日期格式）

ffff：0006的内容是其中的9，查看ASCII码也知道9的ASCII码是57,而57的十六进制数是39.
所以我的电脑中
ffff：0006的内容是39
ffff：0007的内容是2F，（十进制为47，ASCII翻译完为斜杠‘/’）

好了，上面那么多话只是为了说明ffff：0006中的内容是什么而已。
这里问题来了，我在debug中用t命令执行完mov ax,ds:6H之后，ax中的内容是2F39.

由此可见
mov ax,ds:6H
这条语句，不仅将ffff：6单元的内容存入了ax，还将ffff：7单元的内容作为ax的高八位存了进去。
--------------------------------------------------------------------------------------------------

因此，我觉得此处的ffff：6单元代表的是一个字型数据，而不是字节型。
它之所以成了字形是因为寄存器ax是16位的，执行此操作会将ffff：6自动提升八位，也变成了16位。我觉得这是个很合理的解释。

C语言中不是也有一种位数提升么。
int a=100；
double b；
b=a；
我们知道，int型数据占4个字节，double双精度型数据占8个字节。我觉得这里有点类似那个。

我们新开辟出来一个64位的内存空间，如果没有初始化，那么这个内存空间应该存放着垃圾数据。
显然a中的32位数据是占用不完b的64位内存空间的，而我们赋值完毕之后，100还是100.00虽然加了小数点，但大小是相等的。因此我怀疑c的编译器可能存在某种机制，专门在这个赋值的过程中对b的未被占用的内存空间进行清理并进行初始化，可能是全部置零，或别的什么的。
我给忘了。

大家觉得，我上面的分析有没有道理呢？

蓝色流星

学习了。。。。。。。

魔诀

第三章中有详解
mov ax,[bx] 传送的是字单元，也就是十六位
mov al,[bx]  传送的是字节单元，是八位。

kikiatw

看完了一大篇後發現這是基本定址問提,你看到後面還會有BYTE PTR,WORD PTR等你就知道了