[swift-evolution] A proposal for inline assembly

[Ethin Probst]

@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
>
>


-- 
Signed,
Ethin D. Probst