Question

我有一些设计用于处理1-256字节的函数，在嵌入式C平台上运行，其中传递一个字节比传递一个int（一条指令对三条）更快更紧凑，是什么？编码：

接受int，如果为零则提前退出，否则将计数值的LSB复制到unsigned char并在do {} while（ - count）中使用它;循环（参数值256将转换为0，但将运行256次）
接受unsigned char，如果为零则提前退出，并且具有256字节的特殊版本的函数（这些情况将提前知道）。
接受unsigned char，如果为零则运行256次。
有一个类似上面的函数，但是通过包装函数调用它，其行为为（0-255）和（仅256）。
有一个类似上面的函数，但是通过表现为（0-255）和（仅256）的包装器宏来调用它。

当系统忙时，预计函数的内部循环可能占处理器执行时间的15％-30％;它有时会用于少量字节，有时用于大字节。该函数使用的内存芯片具有每事务开销，我更喜欢让我的内存访问函数在内部执行start-transaction / do-stuff / end-transaction序列。

最有效的代码是简单地接受unsigned char并将参数值0视为执行256字节的请求，依赖于调用者以避免任何意外尝试读取0字节。但这似乎有点危险。有其他人在嵌入式系统上处理过这些问题吗？他们是如何处理的？

修改的该平台是PIC18Fxx（128K代码空间; 3.5K RAM），连接到SPI闪存芯片;当预期较少时读取256个字节可能会超出PIC中的读缓冲区。写入256个字节而不是0将破坏闪存芯片中的数据。如果没有检查忙状态，PIC的SPI端口每12个指令时间限制为一个字节;如果有人会慢一些。典型的写事务除了要接收的数据外还需要发送4个字节;读取需要一个额外的字节用于“SPI周转”（访问SPI端口的最快方法是在发送下一个字节之前读取最后一个字节）。

编译器是HiTech PICC-18std。

我一般都喜欢HiTech的PICC-16编译器; HiTech似乎已经将他们的能量从PICC-18std产品转移到他们的PICC-18pro系列，它的编译时间更慢，似乎需要使用3字节'const'指针而不是双字节指针，并且有它的关于内存分配的想法。也许我应该更多地看看PICC-18pro，但是当我尝试在一个版本的PICC-18pro上编译我的项目时，它没有用，我也没弄清楚为什么 - 也许是关于变量布局不同意的事情我的asm例程 - 我只是继续使用PICC-18std。

顺便说一下，我刚刚发现PICC-18特别喜欢do {} while（ - bytevar）;特别不喜欢做{} while（ - intvar）;我想知道当编译器生成后者时，编译器的“思维”是什么？

  do
  {
    local_test++;
    --lpw;
  } while(lpw);

  2533                           ;newflashpic.c: 792: do
  2534                           ;newflashpic.c: 793: {
  2535  0144A8  2AD9                incf    fsr2l,f,c
  2536                           ;newflashpic.c: 795: } while(--lpw);
  2537  0144AA  0E00                movlw   low ?_var_test
  2538  0144AC  6EE9                movwf   fsr0l,c
  2539  0144AE  0E01                movlw   high ?_var_test
  2540  0144B0  6EEA                movwf   fsr0h,c
  2541  0144B2  06EE                decf    postinc0,f,c
  2542  0144B4  0E00                movlw   0
  2543  0144B6  5AED                subwfb  postdec0,f,c
  2544  0144B8  50EE                movf    postinc0,w,c
  2545  0144BA  10ED                iorwf   postdec0,w,c
  2546  0144BC  E1F5                bnz l242

编译器加载指向变量的指针，甚至不使用LFSR指令（可能需要两个单词），而是MOVLW / MOVWF的组合（取四个）。然后它使用此指针进行减量并进行比较。虽然我承认do {} while（ - wordvar）;不能像{}那样产生好的代码（wordvar--）;代码优于后一种格式实际生成的代码。做一个单独的减量和while-test（例如while（--lpw，lpw））产生合理的代码，但它看起来有点难看。后递减运算符可以产生用于递减计数循环的最佳代码：

  decf _lpw
  btfss _STATUS,0 ; Skip next inst if carry (i.e. wasn't zero)
   decf _lpw+1
  bc    loop  ; Carry will be clear only if lpw was zero

但它会产生比--lpw更差的代码。最好的代码是用于向上计数循环：

  infsnz  _lpw
   incfsz _lpw+1
   bra loop

但是编译器没有生成它。

编辑2 我可能使用的另一种方法：为字节数分配一个全局16位变量，并写入函数，以便在退出之前计数器始终为零。然后，如果只需要8位值，则只需要加载8位。我会使用宏来做东西，这样可以调整它们以获得最佳效率。在PIC上，在已知为零的变量上使用| =永远不会比使用=慢，并且有时更快。例如，intvar | = 15或intvar | = 0x300将是两条指令（每种情况只需要打扰结果的一个字节，可以忽略另一个）; intvar | = 4（或2的任何幂）是一条指令。显然在其他一些处理器上，intvar = 0x300会比intvar | = 0x300更快;如果我使用宏，它可以适当调整。

Answer 1

您的内部函数应复制count + 1个字节，例如

 do /* copy one byte */ while(count-- != 0);

如果后减量很慢，其他选择是：

 ... /* copy one byte */
 while (count != 0) { /* copy one byte */; count -= 1; }

或

 for (;;) { /* copy one byte */; if (count == 0) break; count -= 1; }

调用者/包装者可以这样做：

if (count > 0 && count <= 256) inner((uint8_t)(count-1))

或

if (((unsigned )(count - 1)) < 256u) inner((uint8_t)(count-1))

如果你的编译器速度更快。

Answer 2

如果int参数花费3条指令而char参数花费1，则可以为缺少的额外1位传递额外的char参数。看起来很愚蠢，你的（大概是16位）int占用的指令数是8位char的两倍多。

Answer 3

FWIW，我会选择选项＃1的一些变体。函数的界面仍然合理，直观，并且似乎不太可能被错误地调用（如果传入大于256的值，您可能想要考虑要执行的操作 - 仅适用于调试构建的断言）。

我不认为使用8位计数器循环正确次数的次要'hack'/微优化会真的是一个维护问题，而且似乎你做了大量的分析来证明它的合理性。

如果有人喜欢包装，我不会反对包装纸，但我个人倾向于选择方案1。

但是，我反对让公共接口要求调用者传入比他们想要读取的值少一个的值。

处理1-256字节的函数的最佳实践

3 个答案: