[swift-evolution] A proposal for inline assembly

Derrick Ho wh1pch81n at gmail.com
Sat Dec 3 21:17:32 CST 2016

I feel like inline assembly is a very niche idea. Inline assembly is
supported by c and by extension objective-c.

void aCFunction();
void aCFunction() {
int a=10, b;
asm ("movl %1, %%eax;
movl %%eax, %0;"
:"=r"(b) /* output */
:"r"(a) /* input */
:"%eax" /* clobbered register */

I found the assembly code here:

But theoretically you should be able to call this assembly code via
aCFunction() in swift.

I understand that it might be fun to do assembly in swift but I feel like
low level code should stay in its territory; if you want to do low level
programming write c code, if you want to go lower than that, leverage
inline assembly within the boundaries of c.

On Sat, Dec 3, 2016 at 7:23 PM Chris Lattner via swift-evolution <
swift-evolution at swift.org> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161204/5b9e86ea/attachment.html>

More information about the swift-evolution mailing list