> On Dec 3, 2016, at 3:12 PM, Ethin Probst via swift-evolution > <[email protected]> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
