• 深入研究C语言 第一篇


    一. 研究过程

    1.第一章:创建编译环境:

    我们首先下载TC2.0,找到其中与编译连接相关的程序和文件:

    (1) 编译器:TCC.exe

    (2) 连接器:tllike.exe

    (3) 相关文件:c0s.obj、cs.lib、emu.lib、maths.lib

    将文件放在C:C目录下。

    编写程序测试我们的编译环境:

    clip_image002

    在这里我们看到,程序被正常的编译。生成了.exe文件。并且可以正确执行。

    当然,在TC中,c0s.obj、cs.lib、emu.lib、maths.lib这四个文件时在TC目录下的lib文件夹下,但是我们如果将lib文件夹直接放入C:C目录下,程序在编译的时候会提示:

    clip_image004

    C0s.obj:Unable to open file

    这是因为,TCC没有找到lib目录下的c0s.obj文件,我们可以推知,TCC默认在寻找文件的时候只在自己同层的目录下寻找。

    在这里我们发现,我们只用了TCC,并没有用到TLINK。那TLINK的作用是什么呢?

    我们删除TLINK。然后进行编译连接的工作。我们看到:

    clip_image006

    我们看到,TLINK其实是被TCC调用实现功能的。

    书中的解释是:TCC.EXE 将a.c编译成a.obj

    TCC调用TLINK将c0s.obj、cs.lib、emu.lib、maths.lib中的相关代码连接到一起生成.exe文件。

    在刚才的步骤中,虽然我们没有生成.exe,但是我们发现,生成了1.obj。那么,我们把TLINK重新找回来,能不能将这个1.obj连接成.exe呢?

    我们尝试:

    clip_image007

    我们发现我们成功的连接完成。

    当我们用TCC编译时,程序可有两个最大为64K的段,一个段为代码段,栈和数据段共用一个段。我们如何来验证这一点呢?(注:这里其实是用到了后面的内容)。我们编写这样一个程序,让其显示程序运行时CS和SS,DS的值。

    clip_image008

    我们编译运行,查看结果:

    clip_image009

    我们发现,CS是一个值,DS,SS两者值相等。这样也就验证了代码段为一个段,栈和数据段共用一个段。而我们又知道,每个段地址不变,偏移地址从0000-ffff是64K的字节。所以这两个段的最大值是64K。

    另外,我们在CMD中直接输入TCC,会显示出TCC的使用参数,如下:

    clip_image011

    2.第二章:显示函数的段地址和偏移地址:

    我们继续研究第二章的内容:

    在main函数中添加语句,使下面的程序可以打印出所有函数的段地址和偏移地址。

    程序如下:

    clip_image012

    我们最直接的想法是用取地址的方式来查看。我们知道,在C语言中,&的作用是取地址。比如:

    clip_image013

    运行后结果如下:

    clip_image014

    那么,函数是不是也可以这样来取地址呢?我们尝试:

    clip_image015

    在这里,我们直接加类似&f1这样的取地址加函数名的形式可以么?我们分析:在debug中,我们看到子程序调用是都是执行的CALL(地址)的方式。在这里,函数名和标号有着类似的作用,就是方便编程人员编程、方便编译器编译和链接。他的本质应该是一个地址值。

    我们直接编译看看是否会报错,证实我们的猜想。

    clip_image017

    我们发现没有报错。也就说明这里的函数名确实被翻译标号或与标号类似的东西。

    为了方便查看,我们让这些地址以16进制的方式显示出来。结果如下:

    clip_image018

    那么我们所找到的值是不是函数的入口地址呢?我们进入debug查看:

    clip_image020

    我们看到,在01fa中,是我们定义的F1函数中的语句,int a=1;也就是说我们的想法是正确的,在printf中直接取函数的地址输出是可以的。

    但是,我们看到,我们打印出的是函数的偏移地址,段地址如何打印呢?

    我们知道,在C语言中,我们可以直接调用一些汇编的寄存器,而在汇编中,CS寄存器记录的是程序段的段地址,也就是说,我们只要显示出CS,就可以显示出程序段的段地址。

    我们编写:

    clip_image021

    运行后其结果如下:

    clip_image022

    但是这个结果对不对呢?我们还得从debug中验证:

    clip_image024

    我们看到,在Debug中-g运行后的结果与CS的值相同。都是0b3b。这也就说明了程序所显示就是程序在执行时的程序段地址。

    那么这两次执行2.exe所显示的程序段地址为什么会不同呢?我们知道,第一次我们是直接在cmd中运行的2.exe,程序接受系统调用自己执行。而第二次我们是用debug加载进入系统,然后执行。在debug加载的时候,程序被debug加载到了指定的程序段位置。

    二. 附加研究:

    在进行研究时,我发现在C语言显示变量的偏移地址时,不同的变量显示的地址值是不相同的。

    比如,全局变量显示如下:

    clip_image014[1]

    局部变量显示如下:

    clip_image025

    这个结果让我疑惑,但是我想起了局部变量和全局变量的区别,又看到了-32这样的值,我猜想这应该是局部变量记载的是相对位置而不是绝对位置。因为绝对位置不会出现负数。我编写程序如下:

    clip_image026

    在debug中,我-g到第二个printf();函数前,也就是显示出变量a的地址后。

    clip_image028

    通过当前的SS:SP的值与-28进行计算,查看结果单元,发现:

    clip_image030

    这个单元内所存放的数就是变量a的值,也就是说这个单元就是变量a的存储单元。

    所以得出结论:在C语言中,全局变量的地址是记录其存储单元的偏移地址,而局部变量的地址是记录其存储单元与现在栈顶指针的相对位置。

    (注解,重要:在这里后期我在回头看的时候,发现这里使用的是%d方式,这很重要。因为地址是FFE4,这是一个十六进制的数,本应该用%f的方式显示出来。而正是两种数不同的表达和显示方式造成了这样的现象。而非是上面的结论。这里为了过程的完整而保留了这个问题。在此改正。)

  • 相关阅读:
    本站将进行有关《大道至简》的讨论~
    启动一个Rich Web Client的项目:Qomo OpenProject
    JavaScript面向对象的支持(1)
    从基础开始:Qomo OpenProject中的一些关键词(2)
    代码规范性与品质问题~
    任何想法的致命问题,并不在于没有实施条件,而在于根本不被实施
    再谈borland与MS对BUG的不同态度~
    善于使用资源的程序员才是好程序员
    伴随开发人员成长的问题:工程重要,还是算法重要?细节重要,还是架构重要?
    JavaScript面向对象的支持(2)
  • 原文地址:https://www.cnblogs.com/shandianlongxiao/p/4027308.html
Copyright © 2020-2023  润新知