Sun Studio 12：性能分析器

带注释的反汇编代码

带注释的反汇编代码提供了函数或目标模块指令的汇编代码列表，以及与每个指令相关联的性能度量。带注释的反汇编代码有多种显示方法，具体取决于行号映射和源文件是否可用，以及请求带注释的反汇编代码的函数的目标模块是否已知：

如果目标模块未知，则分析器只对指定函数的指令进行反汇编，并且不会在反汇编代码中显示任何源代码行。
如果目标模块已知，则针对目标模块内的所有函数进行反汇编。
如果源文件可用，并且记录了行号数据，则分析器可以根据显示首选项交错显示源代码和反汇编代码。
如果编译器已向目标代码中插入注释，则它也可交错显示在反汇编代码中（如果已经设置了相应的首选项）。

反汇编代码中的每个指令都用以下信息进行注释。

由编译器报告的源代码行号
它的相对地址
指令的十六进制表示（如果要求）
指令的汇编程序 ASCII 表示

调用地址尽可能解析为符号（如函数名称）。度量显示在指令行上，如果设置了相应的首选项，度量还可显示在任何交错显示的源代码中。可能的度量值与前面介绍的源代码注释的度量值一样（请参见表 8–1）。

在多个位置执行 #included 的代码的反汇编代码列表将在每次代码执行 #included 时重复一次反汇编指令。只有重复的反汇编代码块首次显示在某个文件中时，源代码才会交错显示。例如，如果在名为 inc_body.h 的头文件中定义的代码块分别由 inc_body、 inc_entry、inc_middle 和 inc_exit 四个函数 #included，则反汇编指令块将在 inc_body.h 的反汇编代码列表中出现四次，但是源代码仅在四个反汇编指令块的第一个块中交错显示。切换到“源”标签，可以看到与每次重复的反汇编代码对应的索引行。

索引行可以显示在“反汇编”标签中。与“源”标签不同的是，不能直接使用这些索引行进行导航。不过，将光标放在紧挨该索引行下方的其中一条指令上，然后选择“源”标签，可以导航至该索引行中引用的文件。

对其他文件中的代码执行了 #include 操作的文件会将通过该操作包含的代码显示为不与源代码交错显示的原始反汇编指令。不过，将光标放在这些指令中的其中一条指令上，然后选择“源”标签，将打开包含 #included 代码的文件。在显示此文件时选择“反汇编”标签，将显示与源代码交错显示的反汇编代码。

内联函数的源代码可以与反汇编代码交错显示，但宏的源代码则不能与反汇编代码交错显示。

代码未优化时，每个指令的行号按顺序显示，源代码行和反汇编指令的交错显示以预期的方式进行。优化后，后面行的指令有时会显示在前面行的指令前面。分析器的交错显示算法为：只要指令显示为来自第 N 行，该行前所有源代码行（包括第 N 行）都会写入该指令前。优化的一个作用是源代码可以在控制转移指令与其延迟槽指令之间显示。与源代码的第 N 行关联的编译器注释就写在该行之前。

解释带注释的反汇编代码

解释带注释的反汇编代码并不是一件简单的工作。叶 PC 是要执行的下一条指令的地址，因此归属到某个指令的度量应该视为等待执行该指令所用的时间。不过，指令的执行并不总是按顺序发生，而且在记录调用栈时可能存在延迟。要利用带注释的反汇编代码，应该熟悉记录实验的硬件以及装入和执行指令的方式。

接下来的几个小节将讨论有关解释带注释的反汇编代码的一些问题。

指令发送分组

指令按组装入和发送（称为指令发送组）。组中包括哪些指令取决于硬件、指令类型、已执行的指令以及与其他指令或寄存器的各种相关性。因此，可能不会单独发送某些指令，因为它们始终与前一条指令在同一个时钟周期内发送，所以它们从不单独表示下一条要执行的指令。而且，在记录调用栈时，可能有多条指令被视为是下一条要执行的指令。

指令发送规则因处理器类型的不同而不同，并且还取决于高速缓存行内的指令对齐。由于链接程序比高速缓存行要求执行更精确的指令对齐，因此在看上去不相关的函数中进行的更改可能会导致指令的对齐方式不同。不同的对齐方式会引起性能的改进或降级。

下面列举了一种假设情况，即同一个函数在略微不同的环境下进行编译和链接的情况。以下两个输出示例均为 er_print 实用程序的带注释的反汇编代码列表。两个示例中的指令是相同的，但指令的对齐方式不同。

在以下示例中，指令的对齐方式是将 cmp 和 bl,a 两条指令映射到不同的高速缓存行，并且大量的时间都用于等待执行这两条指令。

   Excl.     Incl.
User CPU  User CPU
    sec.      sec.
                             1. static int
                             2. ifunc()
                             3. {
                             4.     int i;
                             5.
                             6.     for (i=0; i<10000; i++)
                                <function: ifunc>
   0.010     0.010              [ 6]    1066c:  clr         %o0
   0.        0.                 [ 6]    10670:  sethi       %hi(0x2400), %o5
   0.        0.                 [ 6]    10674:  inc         784, %o5
                             7.         i++;
   0.        0.                 [ 7]    10678:  inc         2, %o0
## 1.360     1.360              [ 7]    1067c:  cmp         %o0, %o5
## 1.510     1.510              [ 7]    10680:  bl,a        0x1067c
   0.        0.                 [ 7]    10684:  inc         2, %o0
   0.        0.                 [ 7]    10688:  retl
   0.        0.                 [ 7]    1068c:  nop
                             8.     return i;
                             9. }

在以下示例中，指令的对齐方式是将 cmp 和 bl,a 两条指令映射到相同的高速缓存行，并且大量的时间都用于等待执行其中一条指令。

   Excl.     Incl.
User CPU  User CPU
    sec.      sec.
                             1. static int
                             2. ifunc()
                             3. {
                             4.     int i;
                             5.
                             6.     for (i=0; i<10000; i++)
                                <function: ifunc>
   0.        0.                 [ 6]    10684:  clr         %o0
   0.        0.                 [ 6]    10688:  sethi       %hi(0x2400), %o5
   0.        0.                 [ 6]    1068c:  inc         784, %o5
                             7.         i++;
   0.        0.                 [ 7]    10690:  inc         2, %o0
## 1.440     1.440              [ 7]    10694:  cmp         %o0, %o5
   0.        0.                 [ 7]    10698:  bl,a        0x10694
   0.        0.                 [ 7]    1069c:  inc         2, %o0
   0.        0.                 [ 7]    106a0:  retl
   0.        0.                 [ 7]    106a4:  nop
                             8.     return i;
                             9. }

指令发送延迟

有时，会更频繁地出现特定的叶 PC，因为这些 PC 表示的指令在发送前被延迟。导致出现这种情况的原因有多种，以下列出了其中的一些原因：

执行前一条指令用了很长的时间，并且执行不能中断，例如指令陷入内核中时。
运算指令需要的寄存器不可用，因为该寄存器的内容是由前面尚未完成的指令设置的。具有数据高速缓存未命中的装入指令就是这种延迟的一个示例。
浮点运算指令正在等待另一个浮点指令完成。指令不能流水线作业时会出现这种情况，例如平方根和浮点除法。
指令高速缓存不存在包含指令的内存字（指令高速缓存未命中）。
在 UltraSPARC® III 处理器上，装入指令上的高速缓存未命中会阻塞所有后续指令，直到未命中问题得到解决，不管这些指令是否使用正在装入的数据项。在 UltraSPARC II 处理器上，仅阻塞使用正在装入的数据项的指令。

硬件计数器溢出的归属

除 TLB 未命中外，硬件计数器溢出事件的调用栈按指令的顺序记录在后续的某些点上，而不是记录在发生溢出的点上，原因之一是处理由溢出产生的中断所用的时间。对于某些计数器（如发送的周期或指令），这种延迟无关紧要。对于其他计数器（例如，那些计数高速缓存未命中或浮点运算的计数器），度量被归属到导致溢出的指令之外的其他指令。通常，引起事件的 PC 只是记录的 PC 前的几条指令，而这些指令可以在反汇编代码列表中正确定位。但是，如果该指令范围内存在分支目标，那么要分辨哪条指令对应于引起事件的 PC 是很困难的，甚至是不可能的。对于计数内存访问事件的硬件计数器，如果该计数器名称带有加号 + 前缀，则收集器会搜索引起事件的 PC。