16至32位整数转换与性能
我想从数组中加载16位无符号整数，并将这些值用于C语言中的32位无符号计算。我可以选择将这些值存储为16位数组（内存更少）或32位数组（更多内存消耗）。
我的代码应该可以用普通的C编译器编译，并且可以在尽可能多的架构上运行。对于这些组合中的许多组合，很难进行性能测量和汇编代码读取，所以我要求进行理论测试。
换句话说:在什么情况下，16位到32位的无符号整数转换通常会消耗CPU周期？我什么时候可以在不损失CPU周期的情况下使用内存减少的16位阵列？
共有1个答案
我认为所有主要架构都支持来自内存的负载，具有符号扩展和零扩展。x86，ARM和MIPS肯定有这样的加载指令。旧架构和原始微控制器，尤其是 8 位和 16 位微控制器，可能没有这样的指令，因此可能需要多个指令才能获得相同的结果。如果你不提这些，你可能并不在乎。因此，只需编写可移植的C / C代码即可完成。
-
GCC和Clang似乎对有符号整数和无符号整数之间的加法有不同的解释，这取决于它们的大小。为什么会这样？所有编译器和平台上的转换是否一致？ 举个例子： 结果： 在这两种情况下，我们得到了-1，但其中一个被解释为无符号整数和下溢。我本以为两者都会以同样的方式转化。 那么，为什么编译器会以如此不同的方式转换它们，这保证了一致性吗？我用G11.1.0和Clang12.0测试了这个。以及Arch Linu
-
问题内容： 本机整数算术指令是否比其计数器部件慢（在装有OS的计算机上）？ 编辑：在当前CPU上，例如Intel Core2 Duo，i5 / i7等。 问题答案： 这取决于确切的CPU和操作。例如，在64位Pentium IV上，64位寄存器的乘法要慢得多。Core 2和更高版本的CPU从一开始就设计用于64位操作。 通常，即使是为64位平台编写的代码也使用32位变量，其中的值将适合它们。这主要
-
问题内容： 针对32位JDK构建和编译为32位字节代码的Java代码是否可以在64位JVM中工作？还是64位JVM需要64位字节代码？ 为了提供更多细节，我有在运行32位JVM的Solaris环境中工作的代码，但是现在将JDK和Weblogic Server升级到64位后遇到了问题。 问题答案： 是的，假设您使用平台无关的库，则Java字节码（和源代码）是平台无关的。32与64位无关紧要。
-
问题内容： 我有一个byte [4]，其中包含一个32位无符号整数（按大端顺序），我需要将其转换为long（因为int无法保存无符号数字）。 另外，我该如何做相反（即从包含32位无符号整数的long到byte [4]）呢？ 问题答案： 听起来像是ByteBuffer的工作。 有点像
-
当我以tiff格式打开一个16位图像时，它会以黑色图像的形式打开。16位tiff图像仅在程序ImageJ中打开；但是，它不会在预览中打开。我想知道我现在的选择是什么，以一种不降低分辨率的更简单的方式查看格式，而不是打开ImageJ查看它。我是否应该将其转换为8位格式，但当格式从16位减少到8位时，是否会丢失数据？另外，我正在考虑将tiff图像转换为jpeg，但这会导致分辨率降低吗？
-
我在c编程方面是个新手，我正试图弄清楚更多关于位的知识，二进制E.c.T 例如，我有三个二进制int变量m1=255或11111111；m2=255或11111111（二进制），m3=255或11111111（二进制），m4=0或00000000（二进制）。我试图把所有的主题放在一起到单一的int变量temp。类似于（11111111 11111111 1111111100000000)这里是我的