保留执行管道
经常检查返回类型是否有错误。但是，可以用不同的方式指定将继续执行的代码。
if(!ret)
{
doNoErrorCode();
}
exit(1);
或者
if(ret)
{
exit(1);
}
doNoErrorCode();
重量级CPU可以使用简单的统计来推测在附近/地点附近采取的分支 - 我研究了一种用于分支推测的4位机制（-2,-1,0,+1,+2），其中零是未知的并且2 将被视为真正的分支。
考虑到上面的简单技术，我的问题是如何构建代码。我认为主要编译器和主要体系结构之间必须有一个约定。这是我的两个问题：
- 当代码不是经常访问的循环时，当管道被填充时，哪个布尔值会偏向？
- 关于分支的推测必须从真、假或零开始（管道必须填充一些东西）。可能是哪个？
Return types are frequently checked for errors. But, the code that will continue to execute may be specified in different ways.
if(!ret)
{
doNoErrorCode();
}
exit(1);
or
if(ret)
{
exit(1);
}
doNoErrorCode();
One way heavyweight CPU's can speculate about the branches taken in near proximity/locality using simple statistics - I studied a 4-bit mechanism for branch speculation (-2,-1,0,+1,+2) where zero is unknown and 2 will be considered a true branch.
Considering the simple technique above, my questions are about how to structure code. I assume that there must be a convention among major compilers and major architectures. These are my two questions
- When the code isn't an often-visited loop which boolean value is biased for when the pipeline is being filled ?
- Speculation about branching must begin at either true or false or zero ( the pipeline must be filled with something). Which is it likely to be ?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
不同 CPU 的行为有所不同，并且编译器经常对指令重新排序。
您可以在这些手册中找到所需的所有信息：http://agner.org/optimize/。
在我看来，了解发生情况的唯一方法是读取编译器生成的汇编代码。
The behavior varies among CPUs, and the compiler often reorders instructions.
You will find all the information you need in these manuals: http://agner.org/optimize/.
In my opinion the only way to know what happens is to read the assembly code generated by the compiler.
在 gcc 上，您可以使用
__builtin_expect来为编译器提供分支预测信息。为了使它稍微容易一点，你可以借用 Linux 内核中使用的可能/不可能的宏：然后例如
On gcc you can use
__builtin_expectto provide the compiler with branch prediction information. To make it slightly easier you can then borrow the likely/unlikely macros used e.g. in the Linux kernel:and then e.g.