> On Dec 3, 2016, at 6:42 PM, Ethin Probst <[email protected]> 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 <[email protected]> wrote: >> >>> 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 >> >> > > > -- > Signed, > Ethin D. Probst _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
