简体   繁体   English

许多 Rust 编译器目标定义在数据布局中使用“p270:32:32-p271:32:32-p272:64:64”——这是什么意思?

[英]Many of the Rust Compilers target definitions use “p270:32:32-p271:32:32-p272:64:64” inside the data-layout - what does it mean?

A few days ago, the basic understanding of the data layout strings of Rust compiler, or to be more specific, the underlying LLVM, was already mostly resolved on Stack Overflow .前几天,关于 Rust 编译器的数据布局字符串的基本理解,或者更具体地说,底层的 LLVM,在Stack Overflow上已经基本解决了。 Unfortunately, one thing is still unclear.不幸的是,有一件事还不清楚。

Many Rust compiler targets include p270:32:32-p271:32:32-p272:64:64 inside their data layout string.许多 Rust 编译器目标在其数据布局字符串中包含p270:32:32-p271:32:32-p272:64:64 Examples are i686-unknown-uefi , x86_64-uwp_windows-msvc , x86_64-unknown-uefi , x86_64-unknown-linux_gnu , x86_64-fuchsia , or 86_64-apple-darwin .例如i686-unknown-uefix86_64-uwp_windows-msvcx86_64-unknown-uefix86_64-unknown-linux_gnux86_64-fuchsia86_64-apple-darwin

( These targets can be found here https://github.com/rust-lang/rust/tree/1.52.1/compiler/rustc_target/src/spec. ) 这些目标可以在这里找到https://github.com/rust-lang/rust/tree/1.52.1/compiler/rustc_target/src/spec。

The LLVM Language Reference explains: LLVM 语言参考解释:

p[n]:<size>:<abi>:<pref>:<idx> This specifies the size of a pointer and its and erred alignments for address space n. p[n]:<size>:<abi>:<pref>:<idx>这指定了指针的大小及其地址空间 n 的错误对齐。 The fourth parameter is a size of index that used for address calculation.第四个参数是用于地址计算的索引大小。 If not specified, the default index size is equal to the pointer size.如果未指定,则默认索引大小等于指针大小。 All sizes are in bits.所有大小都以位为单位。 The address space, n, is optional, and if not specified, denotes the default address space 0. The value of n must be in the range [1,2^23).地址空间n 是可选的,如果不指定,则表示默认地址空间0。n 的值必须在[1,2^23) 范围内。

I don't understand this.我不明白这个。 What is so special about p270 to p272 ? p270p272什么p270 To which "address space" are they referring to?他们指的是哪个“地址空间”?

These data layout strings were commited to Rust on 2020-01-07 .这些数据布局字符串已于2020 年 1 月 7 日提交给 Rust The commit message says " Update data layouts to include new X86 address spaces ".提交消息显示“更新数据布局以包含新的 X86 地址空间”。 After more research I found that the underlying functionality was merged into LLVM in 2019 .经过更多研究,我发现底层功能已于 2019 年合并到 LLVM 中 These new address spaces are MSVC's __ptr32 , __ptr64 , __sptr , and __uptr extensions [1 ].这些新地址空间是 MSVC 的__ptr32__ptr64__sptr__uptr扩展 [1 ]。

Quote from the LLVM discussion:引用自 LLVM 讨论:

The numbers 270-272 are more or less arbitrary;数字 270-272 或多或少是任意的; I picked them because they're near 256-258, which are the current existing address spaces.我选择它们是因为它们靠近 256-258,这是当前存在的地址空间。

If you look into X86.h in LLVM's source code , one can see that this number is used as identifier and is chosen at will but not for technical reasons.如果您查看LLVM 源代码中的X86.h您会发现这个数字被用作标识符并且是随意选择的,但不是出于技术原因。

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM