Talk:X32 ABI

Latest comment: 1 year ago by Agnerf in topic x86-64 ABI?

Both faster and slower? edit

"On average x32 is 5–8% faster on the SPEC CPU integer benchmarks compared to x86-64 but it can as likely be much slower."

How can something, on average, be both faster and much slower?

I'd take a stab at fixing the sentence, but I don't know what it's trying to say.

108.64.117.104 (talk) 07:25, 30 September 2013 (UTC)Reply

x32 for ARM64? edit

I know x32 is x86-64 specific, but I would like to know when something similar is done for ARM64 (ARMv8-A) - the new ARM architecture. See: [1] Seems just as needed/useful there. If implemented as a version of x32 belongs here or maybe even plans (not that I know of) would belong here. [For other eg. SPARC and POWER, 64- and 32-bit are really the same (if minor change) instruction sets, and maybe something for them is trivial or already "done".] comp.arch (talk) 11:17, 26 September 2014 (UTC)Reply

Glibc Support edit

...says citation needed, https://sourceware.org/ml/libc-alpha/2012-06/msg00807.htm looks suitable. Tried to add it but WP refuses to format it properly. — Preceding unsigned comment added by Ewx (talkcontribs) 21:39, 10 July 2016 (UTC)Reply

Max Memory per Process in x86-64 edit

The table comparing x32 and x86-64 specifies that the max memory per process in x86-64 is 128 terabytes, but it seems like that should be 256 terabytes. The x86-64 page has a section on canonical form addresses that details why the limit is 256 terabytes, instead of the 2^64 bytes that some people might expect. I don't see any mention of 128 terabytes, and it's not clear where that number come from with regards to Linux (it seems like that might be a limit for modern Windows processes, but since this is a Linux specific ABI, it doesn't make much sense to talk about Windows specific limits) — Preceding unsigned comment added by 64.94.36.4 (talk) 16:09, 22 January 2018 (UTC)Reply

x86-64 ABI? edit

We need a separate Wiki page on the x86-64 / System V ABI. Agnerf (talk) 06:04, 4 June 2022 (UTC)Reply