当指针不在CPU寄存器中时,是否可以将具有两个高位零字节的指针存储为一个WORD?

发布于 2024-09-30 11:49:50 字数 276 浏览 3 评论 0原文

在指针大小为 4 字节的系统上,当目的只是寻址可通过两个字节(较低部分)寻址的内存部分时,是否可以将指针存储为两字节 WORD(当指针不在某些 cpu 中时)登记?我没有看到任何原因假设我们通过声明一个指针来获得任何像名为“twoBytes”的单词:

char * pointer = reinterpret_cast<char *>((unsigned int)(twoBytes))

我们正在引入一个具有 4 字节的全新实体,它将被保存为 4 字节实体。

On a system where size of a pointer is 4 bytes when the intention is to just address parts of memory that are addressable by two bytes(lower parts), is it possible to store the pointer as a two byte WORD when it's not in some cpu register? I don't see any way cause assuming we've got any WORD like one named "twoBytes" by declaring a pointer like:

char * pointer = reinterpret_cast<char *>((unsigned int)(twoBytes))

We're introducing a whole new entity with 4 bytes that's gonna be saved as a 4-byte entity.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

噩梦成真你也成魔 2024-10-07 11:49:51

一般来说,您可以存储恢复原始指针值所需的很少的信息,所以是的,您可以,尽管它超出了语言提供的保证(您需要确定您的特定编译器如何处理重新解释强制转换)。

然而,在例如Windows 中,您唯一可以确定的是,对于用户代码来说,32 位指针的高位字非零(空指针除外)。这是隐含在 Windows API 宏中的,例如 MAKEINTATOM。如果最高有效字可能为零,则 API 无法可靠地区分代表小整数的指针和指向文本字符串的指针。

因此,一般来说,除非您正在进行内核编程,否则这种优化方式不会给您带来任何好处。而且,为了节省几个字节而增加复杂性是不值得的。

干杯&呵呵,

Generally you can store however little information is needed to recover the original pointer value, so yes, you can, although it's outside the guarantees offered by the language (you need to be sure how your particular compiler treats reinterpret casts).

However, in e.g. Windows the only thing you can be sure of is that the upper word of a 32-bit pointer is non-zero for user code (except for nullpointers). This is implicit in the Windows API macros like MAKEINTATOM. If the most significant word could be zero then the APIs couldn't reliably distinguish pointers that represent small integers, from pointers to text strings.

So, in general, optimizing that way won't buy you anything unless you're doing kernel programming. Also, saving a few bytes is seldom worth the added complexity.

Cheers & hth.,

百善笑为先 2024-10-07 11:49:51

您所描述的内容听起来更像是编译器功能(老式的“近”指针),而不是您可以从语言内部执行的操作。与您正在使用的编译器的制造者联系。我可以保证在 GCC 中实现这种行为的理论上的可能性,尽管我怀疑这会是一个巨大的痛苦。

作为一种替代方法,您也许可以使用基指针和“无符号短”偏移量来获得您想要的大部分内容。

What you are describing sounds more like a compiler feature (good old fashioned "near" pointers) than something you can do from inside the language. Take it up with whoever made the compiler you're using. I can vouch for the theoretical possibility of being able to implement this behavior in GCC, although I suspect it would be a huge pain in the ass.

As an alternative hack, you might be able to get most of what you want using a base pointer and 'unsigned short' offsets.

梦途 2024-10-07 11:49:51

不,出于同样的原因,您不能将“自行车”一词存储在两个字节中。数据根本不适合。不要将指针强制转换为非指针类型,它通常是不可移植的,并且可能会默默地引入截断并导致一些讨厌的错误。

No, for the same reason you can't store the word "bike" in two bytes. The data just won't fit. Don't cast pointers to non-pointer types, it's often non-portable and can silently introduce truncation and cause some nasty bugs.

同展鸳鸯锦 2024-10-07 11:49:51

您也可以在没有命名 4 字节实体的情况下使用它:

((char*)(unsigned)twoBytes)[idx] = some_val;

twoBytes 将仅占用内存中的两个字节。当您将其转换为 char* 时,编译器将生成一个 4 字节值来实际寻址数据,但您永远不会看到它,并且它可能只存在于寄存器中。我想这就是你问的。

You can also use it without a named 4 byte entity:

((char*)(unsigned)twoBytes)[idx] = some_val;

twoBytes will only take up two bytes in memory. When you cast it to a char*, your compiler will make a 4-byte value to actually address the data, but you'll never see it, and it will likely only ever be in a register. I think that's what you were asking.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文