@@ -735,22 +735,22 @@ Vim 能够解释这样的标记：
735735
736736 第十九章：内联汇编
737737
738- 在特定架构的代码中，你也许需要内联汇编来使用 CPU 接口和平台相关功能。在需要
739- 这么做时，不要犹豫 。然而，当 C 可以完成工作时，不要无端地使用内联汇编。如果
740- 可能 ，你可以并且应该用 C 和硬件交互 。
738+ 在特定架构的代码中，你可能需要内联汇编与 CPU 和平台相关功能连接。需要这么做时
739+ 就不要犹豫 。然而，当 C 可以完成工作时，不要平白无故地使用内联汇编。在可能的情
740+ 况下 ，你可以并且应该用 C 和硬件沟通 。
741741
742- 考虑去写通用一点的内联汇编作为简明的辅助函数，而不是重复写下它们的细节。记住
743- 内联汇编可以使用 C 参数。
742+ 请考虑去写捆绑通用位元 (wrap common bits) 的内联汇编的简单辅助函数，别去重复
743+ 地写下只有细微差异内联汇编。记住内联汇编可以使用 C 参数。
744744
745- 大而特殊的汇编函数应该放在 .S 文件中，对应 C 的原型定义在 C 头文件中。汇编
746- 函数的 C 原型应该使用 “asmlinkage”。
745+ 大型，有一定复杂度的汇编函数应该放在 .S 文件内，用相应的 C 原型定义在 C 头文
746+ 件中。汇编函数的 C 原型应该使用 “asmlinkage”。
747747
748- 你可能需要将你的汇编语句标记为 volatile，来阻止 GCC 在没发现任何副作用后就
749- 移除了它 。你不必总是这样做，虽然，这样可以限制不必要的优化 。
748+ 你可能需要把汇编语句标记为 volatile，用来阻止 GCC 在没发现任何副作用后就把它
749+ 移除了 。你不必总是这样做，尽管，这不必要的举动会限制优化 。
750750
751- 在写一个包含多条指令的单个内联汇编语句时，把每条指令用引号字符串分离，并写在
752- 单独一行，在每个字符串结尾，除了 \n\t 结尾之外，在汇编输出中适当地缩进下
753- 一条指令 ：
751+ 在写一个包含多条指令的单个内联汇编语句时，把每条指令用引号分割而且各占一行，
752+ 除了最后一条指令外，在每个指令结尾加上 \n\t，让汇编输出时可以正确地缩进下一条
753+ 指令 ：
754754
755755 asm ("magic %reg1, #42\n\t"
756756 "more_magic %reg2, %reg3"
@@ -759,33 +759,34 @@ Vim 能够解释这样的标记：
759759
760760 第二十章：条件编译
761761
762- 只要可能，就不要在 .c 文件里面使用预处理条件；这样做让代码更难阅读并且逻辑难以
763- 跟踪 。替代方案是，在头文件定义函数在这些 .c 文件中使用这类的条件表达式，提供空
764- 操作的桩版本（译注：桩程序，是指用来替换一部分功能的程序段）在 #else 情况下，
765- 再从 .c 文件中无条件地调用这些函数。编译器会避免生成任何桩调用的代码，产生一致
766- 的结果 ，但逻辑将更加清晰。
762+ 只要可能，就不要在 .c 文件里面使用预处理条件 (#if, #ifdef)；这样做让代码更难
763+ 阅读并且更难去跟踪逻辑 。替代方案是，在头文件中用预处理条件提供给那些 .c 文件
764+ 使用，再给 #else 提供一个空桩 (no-op stub) 版本，然后在 .c 文件内无条件地调用
765+ 那些 (定义在头文件内的) 函数。这样做，编译器会避免为桩函数 (stub) 的调用生成
766+ 任何代码，产生的结果是相同的 ，但逻辑将更加清晰。
767767
768- 宁可编译整个函数，而不是部分函数或部分表达式。而不是在一个表达式添加 ifdef，
769- 解析部分或全部表达式到一个单独的辅助函数，并应用条件到该函数内。
768+ 最好倾向于编译整个函数，而不是函数的一部分或表达式的一部分。与其放一个 ifdef
769+ 在表达式内，不如分解出部分或全部表达式，放进一个单独的辅助函数，并应用预处理
770+ 条件到这个辅助函数内。
770771
771- 如果你有一个在特定配置中可能是未使用的函数或变量，编译器将警告它定义了但未使用，
772- 标记这个定义为 __maybe_unused 而不是将它包含在一个预处理条件中。（ 然而，如果
773- 一个函数或变量总是未使用的 ，就直接删除它。）
772+ 如果你有一个在特定配置中，可能变成未使用的函数或变量，编译器会警告它定义了但
773+ 未使用，把它标记为 __maybe_unused 而不是将它包含在一个预处理条件中。( 然而，如
774+ 果一个函数或变量总是未使用 ，就直接删除它。)
774775
775- 在代码中，可能的情况下，使用 IS_ENABLED 宏来转化某个 Kconfig 标记为 C 的布尔
776- 表达式，并在正常的 C 条件中使用它：
776+ 在代码中，尽可能地使用 IS_ENABLED 宏来转化某个 Kconfig 标记为 C 的布尔
777+ 表达式，并在一般的 C 条件中使用它：
777778
778779 if (IS_ENABLED(CONFIG_SOMETHING)) {
779780 ...
780781 }
781782
782- 编译器会无条件地做常数合并，就像使用 #ifdef 那样，包含或排除代码块，所以这不会
783- 带来任何运行时开销 。然而，这种方法依旧允许 C 编译器查看块内的代码，并检查它的正确
784- 性（ 语法，类型，符号引用，等等） 。因此，如果条件不满足，代码块内的引用符号将不存在，
785- 你必须继续使用 #ifdef。
783+ 编译器会做常量折叠，然后就像使用 #ifdef 那样去包含或排除代码块，所以这不会带
784+ 来任何运行时开销 。然而，这种方法依旧允许 C 编译器查看块内的代码，并检查它的正
785+ 确性 ( 语法，类型，符号引用，等等) 。因此，如果条件不满足，代码块内的引用符号就
786+ 不存在时，你还是必须去用 #ifdef。
786787
787- 在任何有意义的 #if 或 #ifdef 块的末尾（超过几行） ，在 #endif 同一行的后面写下
788- 注释，指出该条件表达式被使用 。例如：
788+ 在任何有意义的 #if 或 #ifdef 块的末尾 (超过几行的) ，在 #endif 同一行的后面写
789+ 下注解，注释这个条件表达式 。例如：
789790
790791 #ifdef CONFIG_SOMETHING
791792 ...
0 commit comments