Skip to content

Document min pointer width. #834

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 3 commits into from
Aug 14, 2020
Merged

Document min pointer width. #834

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
9616401
Document min pointer width.
ehuss Jun 15, 2020
603cefc
Add note clarifying 16-bit support.
ehuss Jul 12, 2020
e28d1de
Apply joshtriplett's suggestion
ehuss Jul 17, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 6 additions & 4 deletions src/conditional-compilation.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -169,11 +169,13 @@ on the endianness of the target's CPU.

### `target_pointer_width`

Key-value option set once with the target's pointer width in bits. For example,
for targets with 32-bit pointers, this is set to `"32"`. Likewise, it is set
to `"64"` for targets with 64-bit pointers.
Key-value option set once with the target's pointer width in bits.

<!-- Are there targets that have a different bit number? -->
Example values:

* `"16"`
* `"32"`
* `"64"`
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this allow targets where pointers are really 24-bits, such as the 65816?
Technically speaking, I forcibly extend pointers to 32-bit, but they only have 24 significant bits.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two separate questions to answer here, I think.

First, whether pointer size here refers to the "significant bits" or the actual size of a pointer value. I think it refers to the latter, so even if you only have 24 significant bits, if you extend pointers to 32-bit then the pointer size is 32-bit.

But if you don't extend pointers, then that raises an interesting question. I don't see a fundamental reason why (for instance) we couldn't support systems with 80-bit pointers and 80-bit usize, or why it would have to be rounded up to 128-bit, as long as LLVM (or whatever backend we used for the platform) supported those 80-bit values.

If we add mentions of such cases, though, then I think we'd need to change the clarifying note I suggested to say that "Many pieces of Rust code may assume that pointers, usize, and isize are either 32-bit or 64-bit". Because a system with 40-bit or 48-bit or 56-bit pointers would likely run into many of the same difficulties and limited library support as a system with 16-bit or 24-bit or 80-bit or 128-bit pointes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I extend pointer size to a multiple of the alignment, 4-bytes. However I treat the 4th byte as padding, rather than treat it as part of the value.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The listed values are only intended as examples, not something exhaustive. However, rustc currently only supports 16, 32, and 64. It seems like to me that the language definition does not need to take a stance on anything other than the minimum, at least for now.


### `target_vendor`

Expand Down
7 changes: 7 additions & 0 deletions src/types/numeric.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -38,3 +38,10 @@ platform's pointer type. The theoretical upper bound on object and array size
is the maximum `isize` value. This ensures that `isize` can be used to calculate
differences between pointers into an object or array and can address every byte
within an object along with one byte past the end.

`usize` and `isize` are at least 16-bits wide.

> **Note**: Many pieces of Rust code may assume that pointers, `usize`, and
> `isize` are either 32-bit or 64-bit. As a consequence, 16-bit
> pointer support is limited and may require explicit care and acknowledgment
> from a library to support.