c++ - C/C++ 将 int 转换为 short 和内联 asm(特定于 ARM)

Question

这不是一个微不足道的问题。
注意:我不需要意见或建议来使用纯 asm。我实际上需要完成我正在谈论的事情:在将结果分配给 short int 时获得没有此符号/零扩展 optcode 的内联 asm。

我正在处理一个将 16 位短裤用于许多功能的库，我正在优化它。我需要使用内联 asm 添加一些优化函数。问题是在很多地方函数的结果被分配给一个短整型。即，编译器生成 uxth 或 sxth arm 操作码。

我的目标是避免这个问题并确保不会生成这个无用的操作码。首先，我需要定义我的优化函数来返回 short int。这样，如果它被分配给一个 int 或一个 short int，就没有额外的操作码来转换结果。

问题是我不知道如何跳过编译器在我自己的函数中生成的 int->short 转换。
像这样的愚蠢 Actor : *(short*)(void*)&value 不起作用。编译器要么开始弄乱堆栈，使问题变得更加严重，要么它仍然使用相同的 sxth 对结果进行符号扩展。

我为多个编译器编译，我能够为 arm 的 armcc 编译器解决它，但我无法用 GCC 完成它(我用 4.4.3 或 4.6.3 编译)。对于 armcc，我在内联 asm 语句中使用短类型。在 gcc 中，即使我使用短编译器仍然出于某种原因认为需要符号扩展。

这是一个简单的代码片段，我无法使用 GCC，关于如何让它工作有什么建议吗？对于这个简单的示例，我将使用 clz 指令:

示例文件 test.c 文件:

static __inline short CLZ(int n)
{
    short ret;
#ifdef __GNUC__
    __asm__("clz %0, %1" : "=r"(ret) : "r"(n));
#else
    __asm { clz ret, n; }
#endif
    return ret;
}

//test function
short test_clz(int n)
{
    return CLZ(n);
}

这是我使用 armcc -c -O3 得到的预期结果:

test_clz:
    CLZ      r0,r0
    BX       lr

这是 GCC -c -O3 给我的 Not Acceptable 结果:

test_clz:
    clz r0, r0
    sxth    r0, r0
    bx  lr

另请注意，如果使用内部变量 int ret; 而不是 short ret; 重写 CLZ，则 armcc 会生成与 GCC 相同的结果。

使用 gcc 或 armcc 获取 asm 输出的快速行:
gcc -O3 -c test.c -o test.o && objdump -d test.o > test.s
armcc -O3 --arm --asm -c test.c

Answer 1

编译器改变了。特别是 gcc，您今天想出的技巧明天或昨天就不会奏效。并且不会跨编译器(armcc、clang 等)一致地工作。

1) 移除短裤并替换为 int 并解决它，这是一个选项，这是最不痛苦的解决方案。

2)如果你想要特定的asm，就写特定的asm，不要乱来。也是一种选择。

虽然很可能编写出始终比其他代码编译得更好的代码，但您无法始终准确地获得所需的代码序列，而不是始终如一。从长远来看，你是在伤害自己，甚至是编写自己的 asm 解决方案。您实际正在寻找的解决方案是遍历代码并将短裤替换为整数，这将生成始终如一地比在那里放短裤更好地编译的代码。总的来说，这将花费更少的时间，并且不必随着编译器的变化每隔几个月就重写一次。

要一劳永逸地完全控制它，可以编译为 asm 或反汇编并删除有问题的指令，将函数留在 asm 中。快速轻松地完成任务，会给你想要的，以消除这种开销，只是留下一些不太容易维护的东西。实际上，由于您让 armcc 执行您想要在 armcc 中编译为 asm 的操作，然后针对 gnu 汇编程序的愚蠢习惯对其进行修补，并将其用作一个解决方案(至少可以编写同时汇编 arm 工具和 gnu 的 asm在 arm ads 的日子里，在我无法访问这些工具之前没有太多的 rvct 时间)。

有多种方法可以获取您提供的确切示例以给出您所追求的确切结果，但我严重怀疑这就是您所追求的，您会编写两行 asm 并完成。我的猜测是你试图在一个函数中内联一些东西(比 CLZ 大)，同时仍然称它为 short，当调用它时 int 会在没有内联 asm 的情况下给你你想要的东西。 (我仍然看不出内联 asm 在短时间内实现和测试的时间比更改变量声明要少得多，输入更少，读取和测试的代码量相同)。

所以这是你的现实:

1) 忍受短裤及其副作用

2) 将它们更改为整数

花几天、几周或几个月的时间做某事没什么大不了的。大多数情况下，避免做某事需要几天、几周、几个月的时间。然后无论如何你都必须这样做，所以现在你有 2xdays，2xweeks，2xmonths......你必须或者应该测试它无论什么解决方案，你正在更改代码，所以这不是一个变化的因素决定。使用内联 asm 攻击编译器是您的最高风险，如果测试确实在时间等式中发生变化，则应该进行最多的测试。需要几个 gcc 版本，并且每 6 个月重新测试一次。

通常，asm 解决方案是在 abi 发生变化时，重新测试之间可能间隔 10 年，而当我们从 64 位到 128 位时，修复 C 可能需要 20 年。但是 32 位到 64 位的过渡仍在继续，我们还没有开始 ARM 32 位到 64 位的过渡/混合(不会放弃所有 64 位的 32 位 arm 处理器，两者都会保留)。后端会一团糟，我现在不会和他们一起玩游戏。在不依赖代码中 int 大小的情况下制作干净的、可移植的 C 语言(假设/要求最少 32 位，但确保它是 64 位干净的)是最便宜的解决方案。