Dan Gohman (Aug 05 2021 at 18:11): Dan Gohman (Aug 05 2021 at 18:11):Here's an example of at least some people in the C++ community thinking about prioritizing 64-bit targets: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2137r0.html#platforms
Chris Fallin (Aug 05 2021 at 18:14):The world is certainly easier to deal with if everything is a little-endian 64-bit desktop core :-)
Chris Fallin (Aug 05 2021 at 18:14):What sort of implications would this actually have though, if the standard still supports platforms with 32-bit pointers?
Chris Fallin (Aug 05 2021 at 18:15):(I guess I should just read it fully to find out)
Dan Gohman (Aug 05 2021 at 18:19):In a 64-bit only world, it'd be easier to make techniques where you squirrel extra bits into a pointer portable. It'd be easier to standardize on "LP64" as the only data model, ending decades of needless complexity caused by C data models being a thing. It'd be easier to specify raw-data interchange formats because you only need to know where the pointers are, and not what the offsets to everything are.
Chris Fallin (Aug 05 2021 at 18:22):I guess the distinction I'm wondering about is between "prefer 64-bit" and "the standard actually says that sizeof(void*) == 8"; it seems to me that a spec usually dictates things like the latter? perhaps the "preference" just means that there will be features that work only for 64-bit pointers?
Dan Gohman (Aug 05 2021 at 18:29):Yeah, the context for that paper was that they're looking to put out a vision and see what kinds of ideas they can build consensus on before moving forward with actual proposals.
Dan Gohman (Aug 05 2021 at 18:30):Note that that is just a paper, and not necessarily the view of the committee as a whole.
Anton Kirilov (Aug 16 2021 at 15:54):I just skimmed through the linked section, but I'd like to mention that prioritizing 64-bit targets doesn't necessarily mean just deprioritizing 32-bit or older targets. For example, Arm is researching an 128-bit capability architecture called Morello, which actually doesn't fit neatly into the model because the virtual address space is still 64-bit, but sizeof(void *) == 16 and "squirreling extra bits into a pointer" is probably not going to work (capability bound representation issue).
Dan Gohman (Aug 16 2021 at 16:02):I know people who are looking forward to wasm64 because they have "standardized on 64-bit" within their C++ codebases, and are planning to use wasm rewriting tools on it to convert it to wasm32 to that it can run in today's wasm engines.
Dan Gohman (Aug 16 2021 at 16:03):I've talked with people who were surprised that we did wasm32 at all. "Isn't everything 64-bit these days?"
Dan Gohman (Aug 16 2021 at 16:04):The C++ world is diverse, and not everyone thinks this way, but my impression is that quite a few people are hoping that x86-64 plus aarch64 means they don't have to think about any other pointer size ever again.
Anton Kirilov (Aug 16 2021 at 16:15):Well, depending on how capability architectures evolve, that might be too optimistic, but even in a pure 64-bit world Arm has introduced a couple of technologies that don't play well with arbitrary manipulation of pointer bits (e.g. pointer authentication and memory tagging).
Last updated: Nov 22 2024 at 16:03 UTC