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

Question

我有一些设计用于处理1-256字节的函数,在嵌入式C平台上运行,其中传递字节比传递int(一条指令对三条)更快更紧凑,编码它的首选方法是什么:

1. 接受一个int,如果为零则提前退出,否则将计数值的LSB复制到unsigned char并在do {} while( - count)中使用它; 循环(参数值256将转换为0,但将运行256次)
2. 接受unsigned char,如果为零则提前退出,并且具有256字节的特殊版本的函数(这些情况将提前知道).
3. 接受unsigned char,如果为零则运行256次.
4. 有一个像上面这样的函数,但是通过表现为(0-255)和(仅256)的包装函数调用它.
5. 有一个像上面这样的函数,但是通过表现为(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

FWIW，我会选择选项#1 的一些变体。该函数的接口仍然合理、直观，并且似乎不太可能被错误调用（您可能需要考虑如果传入大于 256 的值您想要做什么 - 仅调试构建断言可能是合适的）。

我不认为使用 8 位计数器循环正确次数的小“黑客”/微优化真的会成为维护问题，而且您似乎已经做了相当多的分析来证明它的合理性。

如果有人喜欢包装纸，我不会反对它们，但我个人会稍微倾向于选项 1。

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