Stream: t-compiler

Topic: pointer width vs pointer size vs usize


Nicholas Sim (Apr 11 2019 at 08:49, on Zulip):

I'm attempting to port Rust to a platform (CHERI) which has target_pointer_width = 128, but usize should be u64: the remaining bits are used for capability tagging. It seems that it's quite hard to get a 64-bit usize, as it seems to depend on pointer_size from the data layout. However, it seems that pointer_size is also used for offsets.

I wonder if I'm doing something silly, or if the meaning has been overloaded?
My understanding is that there is no support (currently!) for architectures where pointer width, pointer size, or usize can differ. Is this correct? Or maybe this should "just work" -- I've configured it wrongly?

Happy if anyone can shed light on this!

Zoxc (Apr 11 2019 at 08:53, on Zulip):

usize is the size of a pointer by definition. So it should be u128 then.

oli (Apr 11 2019 at 08:56, on Zulip):

Not only is it defined in Rust that usize is the same size as *const (), but I also believe the compiler can't cope with pointer sizes other than 32 and 64 bit with some minor support for 16 bit

Nicholas Sim (Apr 11 2019 at 09:27, on Zulip):

@Zoxc do you mean usize == uintptr_t, rather than size_t? And since usize is implicitly used for size_t, there is an (assumed) equivalence between the three?

As for coping with other pointer sizes -- I've seen the (16-bit) AVR patches, and I can attest that rustc "copes" with 128-bit target_pointer_width, pointer_size, and usize. The trouble comes when you can't call ptrtoint to the pointer size, or certain GEP indexing operations, etc., where 128-bit operands are not accepted. To an extent, I've solved this using intcasts -- this breaks when with opt-level >= 2

nikomatsakis (Apr 11 2019 at 14:22, on Zulip):

Traditionally, usize == uintptr_t, yes. I can't speak to the rest necessarily.

oli (Apr 11 2019 at 14:28, on Zulip):

const eval will fail guaranteed if you use usize values bigger than u64::max_value

centril (Apr 11 2019 at 14:29, on Zulip):

const eval has a bug ;)

oli (Apr 11 2019 at 14:32, on Zulip):

well... fixing it will regress max-rss even for all hosts

pnkfelix (Apr 11 2019 at 14:33, on Zulip):

because all hosts pay the overhead of whatever the maximum ptr width is?

nagisa (Apr 11 2019 at 14:35, on Zulip):

Might make sense to go to flexible-width integers for all sorts of integral types.

oli (Apr 11 2019 at 14:40, on Zulip):

because all hosts pay the overhead of whatever the maximum ptr width is?

yes

oli (Apr 11 2019 at 14:40, on Zulip):

Might make sense to go to flexible-width integers for all sorts of integral types.

then we'd end up with a pointer to the heap alloc, which is also bigger than 64 bits ;)

oli (Apr 11 2019 at 14:41, on Zulip):

(in total, pointer + data)

nagisa (Apr 11 2019 at 14:41, on Zulip):

Not necessarily.

nagisa (Apr 11 2019 at 14:42, on Zulip):

anything 63-bits long can be represented as a regular tagged integer, anything above as a pointer to integers

oli (Apr 11 2019 at 14:42, on Zulip):

so only heapify if the value is bigger than usize and use some bits to clarify that?

nagisa (Apr 11 2019 at 14:42, on Zulip):

yeah, that’s one of the options

nagisa (Apr 11 2019 at 14:43, on Zulip):

another option is to use indices into some sort of an array, and those can be made smaller -- only as large as necessary to store the necessary number of integers, rather than address the whole address space.

Last update: Nov 22 2019 at 04:30UTC