我有一些用于处理1-256字节的函数，这些函数在嵌入式C平台上运行，在该平台上传递字节比传递int（一个指令对三个指令）要快得多，也更紧凑，这是首选的编码方式：
接受一个int，如果为零则提前退出，否则将计数值的LSB复制到一个无符号字符中，并在do {} while（-count）;中使用它。循环（参数值256将转换为0，但将运行256次）
接受一个无符号字符，如果为零则提前退出，并具有256个字节的特殊版本的函数（这些情况将事先知道）。
接受一个无符号字符，如果为零，则运行256次。
具有上述功能，但可通过包装器函数调用该函数，其表现为（0-255）和（仅256）。
具有上述功能，但可通过表现为（0-255）和（仅256）的包装宏来调用它。
可以预期，当系统繁忙时，函数的内部循环可能会占处理器执行时间的15％-30％。它有时会用于少量的字节，有时会用于较大的字节。该函数使用的内存芯片具有每个事务的开销，我更喜欢让我的内存访问函数在内部执行开始事务/完成事务/结束事务序列。
最有效的代码是简单地接受一个无符号的char并将参数值0视为执行256个字节的请求，这依赖于调用者以避免任何意外尝试读取0个字节。不过，这似乎有些危险。是否有其他人在嵌入式系统上处理过此类问题？他们是如何处理的？
编辑
该平台是PIC18Fxx（128K代码空间； 3.5K RAM），它连接到SPI闪存芯片。如果期望的字节数更少，则读取256个字节可能会超出PIC中的读取缓冲区的范围。写入256个字节而不是0个字节会损坏闪存芯片中的数据。如果不检查繁忙状态，则每12条指令将PIC的SPI端口限制为一个字节。如果这样做会比较慢。典型的写事务除了要接收的数据外还需要发送4个字节。读取需要一个额外的字节来进行“ SPI周转”（访问SPI端口的最快方法是在发送下一个字节之前读取最后一个字节）。
编译器为HiTech PICC-18std。
我通常喜欢HiTech的PICC-16编译器。 HiTech似乎将精力从PICC-18std产品转移到了PICC-18pro系列产品上，该产品系列的编译时间甚至更慢，似乎需要使用3字节的“ const”指针而不是2字节的指针，并且具有关于内存分配的想法。也许我应该更多地关注PICC-18pro，但是当我尝试在评估版的PICC-18pro上编译我的项目时，它不起作用，我也没有弄清楚原因-也许关于变量布局的某些观点与我的asm例程-我一直使用PICC-18std。
偶然地，我发现PICC-18特别喜欢{} while（-bytevar）;特别是不喜欢这样做{} while（-intvar）;我不知道编译器的“思维”在生成后者时会发生什么？
做
{
local_test ++;
--lpw;
} while（lpw）;
2533; newflashpic.c：792：做
2534; newflashpic.c：793：{
2535 0144A8 2AD9 incf fsr2l，f，c
2536; newflashpic.c：795：} while（-lpw）;
2537 0144AA 0E00 movlow低？_var_test
2538 0144AC 6EE9 movff 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 movww 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奔驰L242
编译器甚至不使用LFSR指令（占用两个字），而是结合使用MOVLW / MOVWF（占用四个字）来加载指向变量的指针。然后，它使用此指针进行减量和比较。虽然我承认这样做{} while（-wordvar）;无法产生与{} while（wordvar--）一样好的代码；该代码比后一种格式实际生成的代码更好。分别进行减量和while测试（例如while（--lpw，lpw））会产生合理的代码，但这似乎有点难看。后减运算符可以为递减计数循环产生最佳代码：
decf _lpw
btfss _STATUS，0;如果进位（即不为零），则跳过下一个指令
的_lpw + 1
bc循环;仅当lpw为零时，进位才清晰
但它生成的代码比--lpw更糟糕。最好的代码是用于递增计数循环：
infsnz _lpw
incfsz _lpw + 1
文胸环
但编译器不会生成该代码。
编辑2
我可能会使用的另一种方法：为字节数分配一个全局16位变量，并编写函数，以便计数器始终在退出前归零。然后，如果仅需要8位值，则只需加载8位。我会使用宏来填充内容，以便对其进行调整以获得最佳效率。在PIC上，对一个已知为零的变量使用| =永远不会比使用=慢，有时甚至会更快。例如，intvar | = 15或intvar | = 0x300将是两条指令（每种情况只需要打扰结果的一个字节，而可以忽略另一个字节）； intvar | = 4（或2的任意幂）是一条指令。显然，在其他一些处理器上，intvar = 0x300比intvar | = 0x300要快；如果我使用宏，则可以对其进行适当的调整。
最佳答案
FWIW，我会选择选项＃1的某些变体。该函数的界面保持灵敏，直观，并且不太可能被错误地调用（如果传入的值大于256，您可能要考虑要做什么-仅调试构建的断言可能是合适的）。
我认为使用8位计数器进行正确的次数来进行次要的“破解” /微优化并不会真正引起维护问题，而且看来您已经进行了大量的分析来证明这一点。
如果有人喜欢它们，我不会反对包装器，但是我个人还是会偏向于选项1。
但是，我反对使用公共接口要求调用者传递的值比他们想读的值小一。
关于c - 函数处理1-256字节的最佳实践，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3523698/