6

我正在编写一个 Linux 内核驱动程序（用于 ARM），并且在一个 irq 处理程序中我需要检查中断位。

bit
 0/16  End point 0 In/Out interrupt
       (very likely, while In is more likely)
 1/17  End point 1 In/Out interrupt
 ...
15/31  End point 15 In/Out interrupt

请注意，一次可以设置多个位。

所以这是代码：

int i;
u32 intr = read_interrupt_register();

/* ep0 IN */
if(likely(intr & (1 << 0))){
    handle_ep0_in();
}

/* ep0 OUT */
if(likely(intr & (1 << 16))){
    handle_ep0_out();
}

for(i=1;i<16;++i){
    if(unlikely(intr & (1 << i))){
        handle_ep_in(i);
    }
    if(unlikely(intr & (1 << (i + 16)))){
        handle_ep_out(i);
    }
}

(1 << 0)并且(1 << 16)会在编译时计算，但是(1 << i)不会(1 << (i + 16))。循环中也会有积分比较和加法。

因为它是一个 irq 处理程序，所以应该在最短的时间内完成工作。这让我想我是否需要对其进行一些优化。

可能的方法？

1.拆分循环，好像没什么区别...

/* ep0 IN */
if(likely(intr & (1 << 0))){
    handle_ep0_in();
}

/* ep0 OUT */
if(likely(intr & (1 << 16))){
    handle_ep0_out();
}

for(i=1;i<16;++i){
    if(unlikely(intr & (1 << i))){
        handle_ep_in(i);
    }
}
for(i=17;i<32;++i){
    if(unlikely(intr & (1 << i))){
        handle_ep_out(i - 16);
    }
}

2.移位intr而不是要比较的值？

/* ep0 IN */
if(likely(intr & (1 << 0))){
    handle_ep0_in();
}

/* ep0 OUT */
if(likely(intr & (1 << 16))){
    handle_ep0_out();
}

for(i=1;i<16;++i){
    intr >>= 1;
    if(unlikely(intr & 1)){
        handle_ep_in(i);
    }
}
intr >>= 1;
for(i=1;i<16;++i){
    intr >>= 1;
    if(unlikely(intr & 1)){
        handle_ep_out(i);
    }
}

3.完全展开循环（未显示）。这会使代码有点混乱。

4.还有其他更好的方法吗？

5.还是编译器实际上会生成最优化的方式？

编辑：我正在寻找一种方法来告诉 gcc 编译器展开该特定循环，但根据我的搜索似乎不可能......

4

2 回答 2

5

如果我们可以假设 intr 中设置的位数很少（通常在中断掩码中就是这种情况），我们可以稍微优化一下并编写一个循环，每个位只执行一次：

void handle (int intr)
{
  while (intr)
  {
    // find index of lowest bit set in intr:
    int bit_id = __builtin_ffs(intr)-1;

    // call handler:
    if (bit_id > 16)
      handle_ep_out (bit_id-16);
    else
      handle_ep_in (bit_id);

    // clear that bit
    // (I think there was a bit-hack out there to simplify this step even further)
    intr -= (1<<bit_id);
  }
}

在大多数 ARM 架构上，__builtin_ffs 将编译为 CLZ 指令和一些围绕它的算术。除了 ARM7 和更早的内核之外，它应该对任何东西都这样做。

另外：在嵌入式设备上编写中断处理程序时，函数的大小也会对性能产生影响，因为指令必须加载到代码缓存中。精益代码通常执行得更快。如果您将内存访问保存到不太可能在缓存中的内存，那么一点开销是可以的。

于 2012-09-13T07:43:30.720 回答
1

我自己可能会选择选项 5。代码的可读性，让 gcc 的疯狂优化级别-O3尽其所能。

我见过在那个级别生成的代码，我什至无法理解。

C 中的任何手工优化（除了可能展开和使用常量而不是运行时位移，一个 la 选项 3）不太可能超过编译器本身可以做的事情。

我想你会发现展开可能没有你想象的那么混乱：

if (  likely(intr & 0x00000001)) handle_ep0_in();
if (  likely(intr & 0x00010000)) handle_ep0_out();

if (unlikely(intr & 0x00000002)) handle_ep_in(1);
if (unlikely(intr & 0x00020000)) handle_ep_out(1);

:

if (unlikely(intr & 0x00008000)) handle_ep_in(15);
if (unlikely(intr & 0x80000000)) handle_ep_out(15);

实际上，您可以使用宏使其变得不那么混乱（未经测试，但您应该了解总体思路）：

// Since mask is a constant, "mask << 32" should be too.

# define chkintr (mask, num) \
    if (unlikely(intr & (mask      ))) handle_ep_in  (num); \
    if (unlikely(intr & (mask << 32))) handle_ep_out (num);

// Special case for high probability bit.

if (likely(intr & 0x00000001UL)) handle_ep0_in();
if (likely(intr & 0x00010000UL)) handle_ep0_out();

chkintr (0x0002UL,  1);  chkintr (0x0004UL,  2);  chkintr (0x0008UL,  3);
chkintr (0x0010UL,  4);  chkintr (0x0020UL,  5);  chkintr (0x0040UL,  6);
chkintr (0x0080UL,  7);  chkintr (0x0100UL,  8);  chkintr (0x0200UL,  9);
chkintr (0x0400UL, 10);  chkintr (0x0800UL, 11);  chkintr (0x1000UL, 12);
chkintr (0x2000UL, 13);  chkintr (0x4000UL, 14);  chkintr (0x8000UL, 15);

唯一的进步是手工编码汇编语言，而且 gcc仍然很有可能超越你:-)

于 2012-09-13T07:30:48.933 回答