__pv_stub(x, t, "add", __PV_BITS_31_24)... 为什么 __PV_BITS_31_24 是 0x8100_0000？
__pv_stub(x, t, "add", __PV_BITS_31_24)... why __PV_BITS_31_24 is 0x8100_0000?
函数
__virt_to_phys(unsigned long x)
归结为
__pv_stub(x, t, "add", __PV_BITS_31_24);
__pv_stub 宏扩展为
add t, x, 0x8100_0000
除了在 .pv_table 部分插入指向该指令的指针外，可用于在启动期间修补该添加指令。
我的问题是关于常量 __PV_BITS_31_24。是否有任何理由为其使用值 0x8100_0000。
根据我的理解，这个值使得add指令的12位立即编码字段为481 hex。在启动期间的 运行 时间，函数 __fix_pv_table 将其更改为 4C0 十六进制（假设第一个内存库在 0x8000_0000 处开始）。
值 0x8100_0000 是否如此常见，以至于人们决定在编译期间将其用作默认值，如果它不同，那么无论如何它都会在启动期间修复？或者有一些我完全无法理解的不同原因？
简而言之，因为它设置了第 31 位和第 24 位，因此产生了用于修补偏移量 MSB 的适当指令编码。
请记住，ARM 指令中的立即数常量是从一个 8 位值循环到 32 位字中的 16 个位置之一形成的。汇编初始值 0x81000000 可确保对 31:24 位进行适当的旋转编码，因此随后可以将任何其他 8 位值写入指令的底部字节，而无需担心其余部分。
它同样可能是 0xff000000（或任何其他至少设置了位 24 和 30 或 31 的值），但显然 that particular value was was a relatively arbitrary decision by the maintainer.
函数
__virt_to_phys(unsigned long x)
归结为
__pv_stub(x, t, "add", __PV_BITS_31_24);
__pv_stub 宏扩展为
add t, x, 0x8100_0000
除了在 .pv_table 部分插入指向该指令的指针外，可用于在启动期间修补该添加指令。 我的问题是关于常量 __PV_BITS_31_24。是否有任何理由为其使用值 0x8100_0000。
根据我的理解，这个值使得add指令的12位立即编码字段为481 hex。在启动期间的 运行 时间，函数 __fix_pv_table 将其更改为 4C0 十六进制（假设第一个内存库在 0x8000_0000 处开始）。 值 0x8100_0000 是否如此常见，以至于人们决定在编译期间将其用作默认值，如果它不同，那么无论如何它都会在启动期间修复？或者有一些我完全无法理解的不同原因？
简而言之，因为它设置了第 31 位和第 24 位，因此产生了用于修补偏移量 MSB 的适当指令编码。
请记住，ARM 指令中的立即数常量是从一个 8 位值循环到 32 位字中的 16 个位置之一形成的。汇编初始值 0x81000000 可确保对 31:24 位进行适当的旋转编码，因此随后可以将任何其他 8 位值写入指令的底部字节，而无需担心其余部分。
它同样可能是 0xff000000（或任何其他至少设置了位 24 和 30 或 31 的值），但显然 that particular value was was a relatively arbitrary decision by the maintainer.