8086的地址ffff:ffff和0:ffef回绕问题

debug                                                                                                                                               
  -d   ffff:fff0   
  FFFF:FFF0     00   00   00   00   00   00   00   00-00   00   00   00   00   00   00   00   
  -d   0:ffe0   
  0000:FFE0     0A   A3   DC   0A   A3   E8   0A   89-1E   C2   05   26   8A   46   04   FE   
  0000:FFF0     C0   A2   77   05   56   E8   C3   47-73   02   5E   C3   89   3E   BC   05   
    
  注：   
  FFFF0   +   FFF0   =   10   FFE0 

    这样1最前面的1会出现溢出，从而实际地址应该是0FFE0。但是可以发现，实际上两个地方的内存内容并不一样，为什么呢？

 

    我们使用的DOS（或者是XP下的CMD），它们都是打开A20地址线的，也就是说   d   ffff:fff0其显示的已经是10FFE0的地址的内容了。   
  从80286起由于CPU的寻址实际已经超过了1M的限制，MICROSOFT的DOS就使用了一些技术来使用大于1M的内存，比如扩展内存技术和扩充内存技术。如果使用DOS   6.22   可以尝试不加载HIMEM.SYS   和EMM386.EXE，然后再使用DEBUG   ，就可以看到想要的地址循环效果了。 

 xp下的cmd运行如下图：

   早期的8086只有20根地址线，只能访问1M的地址空间。CPU寻址则按段+偏移的方式进行。16位段+16位偏移的可能的范围是0~0x10FFEF   （即0xFFFF0+0xFFFF），即1M+65520字节的范围。由于只有20根地址线，所以在对1M~1M+65520范围进行访问时，会发生“地址回绕”的现象，就是说实际会访问到0~65520的地方。据说某个著名的/臭名昭著的软件利用了这个特点。在80286，386等CPU上，它会失败，因为这些CPU有多于20根的地址线，并不产生“地址回绕”现象。为了保持完全的兼容性，IBM决定在PC   AT系统上加个逻辑，来模仿以上的回绕特征。他们的方法就是把A20和键盘控制器的一个输出进行AND，这样来控制A20的打开和关闭。一开始时A20是被屏蔽的（总为0），直到系统软件去打开它