[Pitch] Unaligned Loads and Stores from Raw Memory

Andrew_Trick · February 2, 2022, 9:01pm

The UnsafeRawPointer APIs work with imported C unions. You can try it today. This proposal doesn't add anything new in that respect.

Converting from C unions to Swift enums is an unrelated problem. Their layouts are not compatible except in certain single-payload cases dictated by the ABI.

github.com

apple/swift/blob/main/docs/ABIStabilityManifesto.md#enums

# Swift ABI Stability Manifesto

* Authors: [Michael Ilseman](https://github.com/milseman) (compiled through conversations with many others)

## Introduction

### The Big Picture

One of the top priorities for Swift right now is compatibility across future Swift versions. Compatibility aims at accomplishing two goals:

1. **Source compatibility** means that newer compilers can compile code written in an older version of Swift. This aims to reduce the migration pain that Swift developers face when migrating to a newer Swift version. Without source compatibility, projects face version-lock where all source code in a project and its packages must be written in the same version of Swift. With source compatibility, package authors will be able to maintain a single code base across multiple Swift versions while allowing their users to use a newer version of Swift.

2. **Binary framework & runtime compatibility** enables the distribution of frameworks in a binary form that works across multiple Swift versions. Binary frameworks include both a *Swift module file*, which communicates source-level information of the framework's API, and a *shared library*, which provides the compiled implementation that is loaded at runtime. Thus, there are two necessary goals for binary framework compatibility:

    * **Module format stability** stabilizes the module file, which is the compiler's representation of the public interfaces of a framework. This includes API declarations and inlineable code. The module file is used by the compiler for necessary tasks such as type checking and code generation when compiling client code using a framework.

    * **ABI stability** enables binary compatibility between applications and libraries compiled with different Swift versions. It is the focus of the rest of this document.

This document is an exploration and explanation of Swift's ABI alongside the goals and investigations needed before declaring Swift's ABI stable. It is meant to be a resource to the community as well as a declaration of the direction of Swift's ABI.

This file has been truncated. show original

hisekaldma · February 2, 2022, 9:04pm

Interacting with binary serialization formats that require unaligned accesses (e.g. formats like BSON) has been 100% of my use cases. load looks like exactly the right API for that kind of thing, and when it doesn’t work, you’re left thinking that you’re ”holding it wrong”, because surely the whole withUnsafe… dance can’t be the best way.

AlexanderM · April 8, 2022, 8:28pm

I agree with the idea of broadening the current load API to support this, instead of introducing a new one.

The necessity of this workaround (or of others that produce the same outcome) is unsatisfactory for two reasons; firstly it is tremendously non-obvious.

I'm worried that knowing to use loadUnaligned(frombyteOffset:as:) instead would be equally non-obvious.

If loadUnaligned(frombyteOffset:as:) were to exist, would there be any reason to call load(frombyteOffset:as:)? Is there anything I'm overlooking?

jrose · April 8, 2022, 8:49pm

For better or worse, there are platforms that don’t support unaligned loads, and on those platforms this would have to be implemented by loading bytes and stitching them together (effectively memcpy). Even on x86 aligned loads are faster but I don’t know how much statically knowing that buys you.

scanon · April 8, 2022, 9:38pm

Even on x86 aligned loads are faster but I don’t know how much statically knowing that buys you.

It allows you to prevent performance bugs from creeping in by making it so that unaligned accesses will fail, producing easy-to-diagnose errors immediately instead of performance regressions that may go undetected for months.

John_McCall · April 8, 2022, 10:12pm

This proposal is actually in active review, so if you have thoughts about it, please post them there instead of here in the pitch thread.