c - 全局化 2 个小型阵列如何导致性能显着下降？

Question

我有 2 个小型本地数组:

short int xpLeft [4], xpRight [4];

当我将它们设为全局(以不同的方法访问它们，但只能在同一个 C 文件中(例如，其他模块无法访问))时，性能(在摩托罗拉 68000 上)下降。整个基准测试(渲染一个场景的 320 帧)不是 224 个 vblanks(对于本地)，而是突然需要 249 个 vblanks(全局数组)!

我尝试过的:
由于数组中的数据没有在该函数中使用，我虽然那个编译器捕获了它并且没有费心将结果值(从寄存器)写入内存(在 68000 上非常慢的操作 - 访问内存)。因此，我在函数末尾添加了一些小代码来使用这些数组值，并相应地提高了性能成本(仅 1 个 vblank)。

有什么帮助:
我需要检查最终的 ASM 代码(并比较两个版本)，但我不确定如何使用 vbcc 编译器(来自 Dr. Volker)来做到这一点。我尝试了文档中的几个开关，虽然它们确实产生了一些中间输出，但我无法让它提供每个模块的完整 ASM 列表(带有来自 C 的函数名称)。

我刚刚让开关“-k”工作。显然，开关的顺序很重要，我在命令行中找到了一个可以识别它的地方，我终于得到了 *.ASM 输出(不少于 30 万行)，但我终于有了一些东西(带符号的 ASM)挖掘。

我认为正在发生的事情:

1. 将数组设为全局将它们放入 RAM 中的不同地址，内存 Controller 必须访问不同的 bank，而 bankswitch 在目标平台上是一个极其缓慢的操作 -导致 RAS 充电周期(访问不同行的地址)。
2. 指针别名 - 编译器可能生成不同的代码，并且可能实际访问实际内存以进行中间操作 结果——但如果我有每个函数的 ASM 输出，我可以 很容易弄明白

关于为什么会发生这种情况或如何获取每个已编译模块的 vbcc 输出完整列表以及相应的 ASM 代码的任何提示？

使用 ASM 输出，我创建了一个小型测试重现案例:

short int tmpfn1 ()
{
    short int xpLeft [4], xpRight [4];
    short int i, tmp;

    for (i = 0; i < 4; i++)
    {
        xpLeft [i] = 137 + i;
        xpRight [i] = 215 + i;
    }

    tmp = xpLeft [0] + xpRight [0];
    return tmp;
}

这是生成的 ASM。虽然 ASM 是不言自明的，但我还是添加了一些评论:

    public  _tmpfn1
    cnop    0,4
_tmpfn1
    sub.w   #16,a7
    movem.l l4150,-(a7)
    moveq   #0,d1
    lea (0+l4152,a7),a1   ; a1 = &xpLeft [0]
    lea (8+l4152,a7),a2   ; a2 = &xpRight [0]
    move.w  #215,d3    ; d2/d3 = The Bulgarian constants 
    move.w  #137,d2
l4148
    move.w  d1,d0
    ext.l   d0
    lsl.l   #1,d0
    move.w  d2,(0,a1,d0.l)    ; xpLeft [i] = 137 + i;
    move.w  d3,(0,a2,d0.l)    ; xpRight [i] = 215 + i;
    addq.w  #1,d1    ; d1 = Loop Counter (i++)
    addq.w  #1,d2
    addq.w  #1,d3
    cmp.w   #4,d1
    blt l4148    ; Repeat the loop
    move.w  (8+l4152,a7),d0
    add.w   (0+l4152,a7),d0    ; tmp = xpLeft [0] + xpRight [0];
l4150   reg a2/d2/d3
    movem.l (a7)+,a2/d2/d3
    add.w   #16,a7
l4152   equ 12
    rts
; stacksize=28
    opt 0
    opt NQLPSMRBT

现在，我将把数组从本地放置到全局。

这是带有全局变量的代码。

    public  _tmpfn1
    cnop    0,4
_tmpfn1
    movem.l l4150,-(a7)
    moveq   #0,d1
    move.w  #215,d2
    move.w  #137,d3
l4148
    move.w  d1,d0
    ext.l   d0
    lsl.l   #1,d0
    lea _AxpLeft,a0
    move.w  d3,(0,a0,d0.l)
    lea _AxpRight,a0
    move.w  d2,(0,a0,d0.l)
    addq.w  #1,d1
    addq.w  #1,d3
    addq.w  #1,d2
    cmp.w   #4,d1
    blt l4148
    move.w  _AxpRight,d0
    add.w   _AxpLeft,d0
l4150   reg d2/d3
    movem.l (a7)+,d2/d3
l4152   equ 8
    rts
; stacksize=8
    opt 0
    opt NQLPSMRBT

唯一的区别是两条 lea 指令，如果内存正常，最多 16 个周期。
实际函数肯定有其他事情发生，但由于某种原因，它的代码在 ASM 中被混淆了(ASM 中只有 6 行，没有跳转，没有其他标签，什么都没有)。我将继续搜索 ASM，找到代码的确切位置。

Answer 1

正如我所怀疑的那样，有一个与 monster-WTF 编译器相关的时刻。之所以在局部变量的情况下只有 6 行代码，是因为编译器能够弄清楚，那 120 行 C 代码实际上并没有在全局级别上做任何事情，所以它完全忽略了代码完全!这意味着该方法的 ASM 代码就是那 6 行(带有 rts)。然而，这与我得到的基准测试结果没有多大意义(但这将是一个不同的故事)

故事的寓意:通过使变量成为全局变量，编译器实际上费心为函数创建代码(而不仅仅是空的 6 操作 stub )。由于我将所有内容都内联到该函数中，因此没有嵌套函数调用。现在，这显然听起来很荒谬，因为我在目标设备上对变量和输出进行了大约 25 次调试 session 。但是那一刻，我删除了那些外部打印/调试调用，那一定是编译器根本没有生成函数代码的那一刻。真他妈的神奇....