[ABI] Define generic 64-bit address space and spare bits.

[milseman]

Define a generic 64-bit address space ABI which is capped at 56
bits. Switch ppc64 and s390x over to it.

This also allows String to have (roughly) the same representation
across 64-bit platforms.

[milseman]

@swift-ci please test

[davezarzycki]

Can you update the x86_64 comment to be pedantically correct? Specifically: architectural limitations limit the address space to 57 bits, not 56, but this subtle difference doesn't matter because the 57th bit is only set for kernel memory, and kernel space and user space don't (in practice) share pointers, and certainly not Swift pointers with the "extra bits" being used. Living with 56-bits is pragmatic.

If Swift ever is ported to x86_64 kernel space, it'll need to learn now to reset the high eight bits to 0xFF, not 0x00, after extracting the pointer.

[gparker42]

Dave, which architectural limitations are you thinking of? I don't know of any reason why x86_64 could not support full 64-bit addresses. (Current implementations only support 48 and Intel has a plan for 57, but I don't see anything that disallows future expansion to 64.)

[davezarzycki]

Hi @gparker42 – I'm struggling to reconstruct my web browsing history on this subject. I think I read about this in the context of Linux adding five-level page table support or Linus micro-optimizing the Linux system call entry code to use those upper bits to cache information. And my memory might be conflating the interpretation of the Intel documents by the Linux community with the actual documents.

In any case, there are many privileged operations / data structures (mostly VM / hypervisor related) that limit "MAXPHYADDR" (in Intel's terminology) to 52 bits due to reserved low bits (often 12). Perhaps I'm wrongly assuming that this 52-bit physical address limit implies that the logical address space will never be larger than 57 bits. We'd need to ask Intel about what their long-term plans are, but I doubt that we'll get an answer, especially one that we can publicly talk about.

Whatever the outcome may be, these assumptions ought to be documented in this Swift header file.

[davezarzycki]

Ah! I found what I was thinking of: Section 4.1.4 of Intel's ISA document:

CPUID.80000008H:EAX[7:0] reports the physical-address width supported by the processor. (For processors that do not support CPUID function 80000008H, the width is generally 36 if CPUID.01H:EDX.PAE [bit 6] = 1 and 32 otherwise.) This width is referred to as MAXPHYADDR. MAXPHYADDR is at most 52.

(Emphasis added.)

That being said, I think my interpretation is just plain wrong. I cannot find a case where MAXPHYADDR isn't either shifted by 12 to compute the actual hardware address, or a fault/error of some kind will happen if low bits are set (for example, see "IA32_RTIT_OUTPUT_BASE").

This all being said, I don't think Swift is wrong for wanting to use the upper bits of pointers for miscellaneous storage. I just think that more planning is needed. The available bits also don't need to be hardware defined or even universal. With kernel support (or shims around the system calls), an executable could have a custom and arbitrary logical address space size below the hardware limit. One just needs to ensure that all new memory maps are below the self-imposed limit (again, either via kernel support, or via system call shims).

[davezarzycki]

I hate to keep flip flopping on this, but I've now read the Intel multi-level page table section. I think 52 bits is indeed the architectural limit for physical memory. Intel seems to be leaving the door open page-table entries that aren't 4096-byte aligned. Weird.

[milseman]

If this were to change significantly, would we be rolling out a new ABI anyways?

[davezarzycki]

I think Swift is in a difficult position here, because we're trying to predict what Intel will do in the future based on a close reading of their architectural manuals. There is also a secondary prediction about what kernel developers will do once the address space can be bigger. Will it be opt in? Opt out? Unavoidable? What? And how? Given that the future is hard to predict, and given that Swift/Apple cannot force non-Darwin platforms to make larger address spaces be opt in, I'm inclined to say that non-Darwin x86_64 platforms should be conservative and not use any of the high bits. This conclusion is frustrating because there is a real chance the top 8 bits on x86_64 will never be used for logical addressing.

[jckarter]

I suspect that other platforms are already stuck in the bind of needing an opt-in for larger address spaces because of Javascript libraries using NaN-encoding for pointers, which puts a 52-bit limit on the address space.

[davezarzycki]

I'd love to get sign off from x86 kernel developers (Darwin, Linux, etc) that the larger address spaces will be opt it. I can think of a ton of compiler data structures that are ripe for optimizing if 16 or 17 bits of each pointer is available for flags/enums/etc. :-)

[jckarter]

The macOS folks have told us in the past that 56 bits ought to be OK, at least.

[milseman]

@mikeash I think this PR is now meaningless with your changes to SWIFT_ABI_DEFAULT_BRIDGEOBJECT_TAG_64.

[milseman]

Nevermind, this seems to be unrelated. We need to specify the spare bits in addition to the tag bit

[milseman]

@swift-ci please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - af8d7c589b27b6568cbe24980feea787fd845247

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - af8d7c589b27b6568cbe24980feea787fd845247

[jckarter]

Looks good.