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

//file.h
void aCFunction();
//file.m
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:
http://www.ibiblio.org/gferg/ldp/GCC-Inline-Assembly-HOWTO.html

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@swift.org> wrote:

>
> > On Dec 3, 2016, at 3:12 PM, Ethin Probst via swift-evolution <
> swift-evolution@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@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to