连接器使用的地址是虚拟内存地址。物理内存地址要在发起访存操作之后通过MMU单元进行转换才能得到（这个过程设计页表和TLB等机制）。如果虚拟内存地址还未跟物理内存地址绑定，此时还会发生缺页异常陷入内核进行物理内存分配。

只能是虚拟内存，如果用的物理内层就很麻烦，没有可扩展性和可移植性了，而且如果直接操作物理内存，那对应程序员的要求就不是CRUD了。虚拟内存就是那句经典的计算机的话：“计算机什么问题都可以靠增加一层中间层来解决的”

链接器用的是虚拟内存地址（就不用关心是不是和物理设备地址覆盖）使用时通过操作系统内核加载到物理地址上，操作系统通过进程/线程进行管理！ MMU地址转换功能，在保护模式下运行（尽可能避免因虚拟地址相同而导致的数据覆盖） 32位内存应为0到0xefffffff 那么问题来了，对普通程序而言，有虚拟地址方便！但对操作系统开发者而言，恐怕还是得清楚设备地址吧？这个设备地址应该有个标准吧？这样操作系统本身数据才能不与物理设备地址冲突！ 如果设备地址的标准不一，预估cpu应该按照设备地址寻址优先原则（允许覆盖），这也估计是为啥操作系统保护模式内核在高位的一个原因吧？（这样，即使不知新的设备地址（假如设备开发商不通知操作系统开发商）只要内核在高位，大不了重新引导程序加载在空的内存空间上的）

链接器使用的是虚拟地址，如果使用物理地址那么链接的过程将及其复杂并且物理地址用完了就不能再编译，这显然是不行的。

请教老师几个问题啊： Q1：“设备寄存器”有哪些？只知道CPU有寄存器，难道CPU之外的设备也有寄存器？ Q2：“sw_ins((unsigned int)&word, 0);”，调用sw_ins的时候传入了参数，但sw_ins函数的定义中并没有参数啊。 Q3：代码中动态分配的内存是怎么确定地址的？此时程序已经运行，链接器无法参与了。

手动分配和动态分配的地址也是虚拟地址吗？

cpu给定低16位（64kb内的）可做为端口，物理设备开发商可以通过端口方式直接与cpu沟通（可绕过操作系统，不需要操作系统分配地址，但估计会引发中断方式来被操作系统知悉？）也可以通过设备软件加载在内存上通过进程/线程，来与cpu沟通（需要操作系统分配地址）

当然了，除了这种方式，你可以在程序代码中直接给出一个地址，代码如下：int main(){ //把整数0x20000强制转换为int类型的指针 int *p = (int*)0x20000; *p = 0; //动态分配一个int类型大小的内存空间，其首地址返回给addr指针 void* addr = malloc(sizeof(int)); return 0;}这段代码就是让 p 直接指向 0x20000 地址，然后向这个地址上写入 0。不过这个操作极其危险，除非你确切地知道自己在干什么，因为 0x20000 可能是其它重要数据，也可能不是真正的内存单元，而是设备寄存器，更可能什么也没有，即这个地址没有连接任何有效设备。 请教一下，关于上述的文章内容，代码编译后运行在常见的操作系统下，不是必须通过虚拟内存来映射到主存，这段内容可否理解成：我强行让 MMU 把一个虚拟地址转成物理地址，转换后的地址不可控制，然后覆盖新的变量后可能发生异常。

老师，您好，请教一个问题；malloc 分配一个内存地址A以后，然后free A，此时访问A程序一定会崩溃。这个崩溃是谁触发的呢？cpu？还是libc的ptmalloc，还是操作系统？ 调用malloc时，ptmalloc会从系统中已经申请的地址空间中，分配一段虚拟地址，然后把首地址返回。free时，应该是标记了以该地址为首的区域没有人使用了。此时再来访问这个地址时，cpu mmu模块会转换为物理地址（如果没有找到该物理地址，应该会产生缺页终端，加载页并与虚拟地址绑定在一起）；按照这个逻辑，访问这个地址应该不会崩溃呢？谢谢。