[swift-evolution] A proposal for inline assembly

Ethin Probst harlydavidsen at gmail.com
Sat Dec 3 20:42:34 CST 2016

@Chris, I'm having trouble understanding your message. Do you mean
that you hope to implement this soon, or that you don't intend to?
@Félix, no, however I do think it would a good feature to have if you
need to optimize certain lines of code beyond preset optimizer passes.

On 12/3/16, Chris Lattner <clattner at apple.com> wrote:
>> On Dec 3, 2016, at 3:12 PM, Ethin Probst via swift-evolution
>> <swift-evolution at swift.org> wrote:
>> Hello all,
>> My name is Ethin and I am new to this community. However, I certainly
>> am no newbie when it comes to software development, and have emailed
>> all of you to file a proposal of inline assembly in Swift. The
>> assembly language would be within an asm {...} block.
> Hi Ethin,
> While it isn’t a pressing short term priority, I would like to see something
> to address the needs served by inline assembly in Swift at some point.  We
> have a lot of experience from the Clang/C space to draw on here, and there
> are three general approaches supported by Clang:
> 1) “Processor Intrinsics" for instructions.  Compilers for some
> architectures provide this as the only option (Itanium in MSVC IIRC).
> 2) “Microsoft” or “CodeWarrior” style inline assembly, like you show.  This
> doesn’t require the developer to write register constraints, and sometimes
> allows direct use of local variables in the asm block.
> 3) “GCC” style inline assembly, which requires the user to write register
> constraints like “rmi”.
> I’m significantly opposed to ever supporting GCC-style assembly, since it is
> very very common for developers to get the constraints wrong, and the
> compiler knows the instruction set anyway.
> When it comes to #1 vs #2, there are tradeoffs:
> #1 is simpler, doesn’t require language extensions (and can be done today by
> a sufficiently motivated person), and composes better with
> processor-independent intrinsics (like cross platform prefetch operations).
> #2 is better for folks who “think in assembly”, because it has a more
> obvious and direct mapping to it.  It has the additional downside of having
> to deal with multiple dialects of assembly, e.g. AT&T vs Intel syntax.
> -Chris

Ethin D. Probst

More information about the swift-evolution mailing list