[swift-evolution] A proposal for inline assembly

[Chris Lattner]

> On Dec 3, 2016, at 6:42 PM, Ethin Probst <harlydavidsen at gmail.com> wrote:
> 
> @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?

I mean that inline assembly is niche and out of scope for swift 4 stage 1, but that I hope some future version of swift includes it.  I have no plan to implement it.

-Chris

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