Arduino 左移未按预期工作，编译器错误？

Question

uint32_t a = 0xFF << 8;
uint32_t b = 0xFF;
uint32_t c = b << 8;

我正在为 Uno（1.0.x 和 1.5）编译，很明显 a 和 c 应该是相同的值，但它们不是......至少在运行时不会目标。我在主机上编译相同的代码，没有问题。

右移工作正常，左移仅在我移动变量与常量时才有效。

谁能证实这一点？

我在 VS2013 中使用 Visual Micro。使用 1.0.x 或 1.5 Arduino 编译会导致同样的失败。

编辑：

在目标上：

A = 0xFFFFFF00
C = 0x0000FF00

Answer 1

问题与有符号/无符号隐式转换有关。

uint32_t a = 0xFF << 8; 你的意思是

• 0xFF 已声明；这是signed char；
• 有一个0xFFFFFFFF;
• 它被转移了，所以a = 0xFFFFFF00。

注意：这有点错误，请参阅下面的“更正确”版本

如果您想重现相同的行为，请尝试以下代码：

uint32_t a = 0xFF << 8;
uint32_t b = (signed char)0xFF;
uint32_t c = b << 8;

Serial.println(a, HEX);
Serial.println(b, HEX);
Serial.println(c, HEX);

结果是

FFFFFF00
FFFFFFFF
FFFFFF00

或者，换句话说，如果你写

uint32_t a = (unsigned)0xFF << 8;

你知道a = 0x0000FF00。

编译器只有两个奇怪的地方：

1. uint32_t a = (unsigned char)0xFF << 8; 返回 a = 0xFFFFFF00
2. uint32_t a = 0x000000FF << 8; 也返回 a = 0xFFFFFF00。

也许是编译器中的错误类型....

编辑：

正如 phuclv 所指出的，上面的解释略有错误。正确的解释是，使用uint32_t a = 0xFF << 8;，编译器会做这样的操作：

• 0xFF 已声明；这是int；
• 有一个0xFF00；它是一个 int，所以它是负数
• 然后将其提升为uint32_t。由于它是负数，1s 被添加到前面，导致 0xFFFFFF00

与上面的解释不同的是，如果你写uint32_t a = 0xFF << 7;，你得到的是0x7F80而不是0xFFFFFF80。

这也解释了我在上一个答案末尾写的两个“奇怪”的东西。

作为参考，在thread linked in the comment 中有更多关于编译器如何解释文字的解释。特别是在this answer 中有一个表，其中包含编译器分配给文字的类型。在这种情况下（无后缀，十六进制值）编译器会根据适合该值的最小类型来分配此类型：

1. int
2. unsigned int
3. long int
4. unsigned long int
5. long long int
6. unsigned long long int

这导致了更多的考虑：

• uint32_t a = 0x7FFF << 8; 这意味着文字被解释为有符号整数；提升到更大的整数会扩展符号，因此结果是 0xFFFFFF00
• uint32_t b = 0xFFFF << 8; 在这种情况下，文字被解释为无符号整数。因此提升到 32 位整数的结果是 0x0000FF00

Answer 2

这里最重要的是，在 Arduino 中 int 是 16 位类型。这将解释一切

1. 对于uint32_t a = 0xFF << 8：0xFF 的类型为int¹。 0xFF << 8 产生 0xFF00，它是 16 位 int² 中的有符号负值。当再次将int 值分配给uint32_t 变量时，它会在向上转换时进行符号扩展³，因此结果变为0xFFFFFF00U

   李>

2. 以下几行

   uint32_t b = 0xFF;
   uint32_t c = b << 8;
   

   0xFF 在 16 位 int 中是 正，因此 b 也包含 0xFF。然后将其左移 8 位得到 0x0000FF00，因为b << 8 是一个uint32_t 表达式。它比int 更宽，所以这里没有对int 的推广

与uint32_t a = (unsigned)0xFF << 8 类似，输出为0x0000FF00，因为转换为unsigned int 时正数0xFF 仍然是正数。将unsigned int 向上转换为uint32_t 进行零扩展，但符号位已经为零，因此即使您执行int32_t b = 0xFF; uint32_t c = b << 8，高位仍然为零。与 “奇怪” uint32_t a = 0x000000FF << 8 相同。而不是 (unsigned)0xFF 您可以使用完全相同的版本（但更短）0xFFU

OTOH，如果您将 b 声明为 uint8_t b = 0xFF 或 int8_t b = 0xFF，那么情况会有所不同，发生整数提升，结果将类似于第一行 (0xFFFFFF00U)。如果你像这样将 0xFF 转换为 signed char

uint32_t b = (signed char)0xFF;
uint32_t c = b << 8;

然后在提升为 int 时，它将被符号扩展为 0xFFFF。同样，将其转换为 int32_t 或 uint32_t 将导致从 signed char 到 32 位宽值 0xFFFFFFFF 的符号扩展

如果您像 uint32_t a = (unsigned char)0xFF << 8; 那样转换为 unsigned char，则 (unsigned char)0xFF 将使用零扩展名提升为 int⁴，因此结果将与 uint32_t a = 0xFF << 8; 完全相同

总结：如有疑问，请查阅标准。编译器很少对你撒谎

---

¹Type of integer literals not int by default?

整数常量的类型是对应列表中第一个可以表示其值的类型。

Suffix      Decimal Constant          Octal or Hexadecimal Constant
-------------------------------------------------------------------
none        int                       int
            long int                  unsigned int
            long long int             long int
                                      unsigned long int
                                      long long int
                                      unsigned long long int

² 严格来说，像这样转换成符号位是未定义的行为

• 1 << 31 produces the error, "The result of the '<<' expression is undefined"
• Defining (1 << 31) or using 0x80000000? Result is different

³ 规则是加UINT_MAX + 1

否则，如果新类型是无符号的，则在新类型可以表示的最大值的基础上反复加减一，直到该值在新类型的范围内。

• Signed to unsigned conversion in C - is it always safe?

⁴如果输入值适合目标类型，则转换将始终保留输入值，因此将有符号类型转换为更广泛的有符号类型将通过符号扩展完成，并转换为无符号类型到更广泛的类型将通过零扩展来完成

Answer 3

[感谢 Mats Petersson]

使用强制转换运算符强制编译器将 0xFF 视为 uint32_t 解决了该问题。似乎 Arduino xcompiler 对常量的处理方式略有不同，因为我从未在轮班之前进行过强制转换。

谢谢！