[swift-dev] Proof-of-concept port of Swift for Android

[Joe Groff]

> On Dec 11, 2015, at 9:03 AM, Geordie Jay <geojay at gmail.com> wrote:
> 
> Hi Joe,
> I was just commenting on your @_cdecl commit on GitHub but I’ll keep the discussion here.
> 
> I was wondering what it is about your implementation that makes it rely on ObjC interop, as you noted. And whether this dependency can be removed for a quick and dirty proof of concept, or whether it’s something more fundamental than that?

It's mostly because that's how the parameter type validation logic I borrowed from @objc works, and I didn't have time to change it. The code for @cdecl has to be refined to support a "C-only" model, or maybe just only require ObjCInterop and 'import Foundation' when ObjC-specific constructs are used.

> 
> In this (admittedly very simple) example, the author just calls the mangled name from C and appears to get away with it:
> http://romain.goyet.com/articles/running_swift_code_on_android/ <http://romain.goyet.com/articles/running_swift_code_on_android/>
> 
> Makes me wonder whether the @_silgen_name approach wouldn’t suffice after all for a proof of concept?

They're getting lucky. Swift function ABIs happen to coincide with C function ABIs in some cases, but this can't be relied on, and will probably break soon when we switch over the Swift-specific calling convention in LLVM.

-Joe

> Best regards,
> Geordie
> 
> (Joe: apologies for the double up, I’m evidently terrible at mailing lists and hit reply instead of reply all!)
> 
> 
> On Fri, Dec 11, 2015 at 5:53 PM, Joe Groff <jgroff at apple.com <mailto:jgroff at apple.com>> wrote:
> 
> 
> > On Dec 11, 2015, at 7:13 AM, Douglas Gregor via swift-dev <swift-dev at swift.org> wrote: 
> > 
> > 
> >> On Dec 11, 2015, at 4:33 AM, Geordie Jay via swift-dev <swift-dev at swift.org> wrote: 
> >> 
> >> Hi, maybe one of the Apple devs can help out with this quick Q: 
> >> 
> >> To interface with the JNI, we’d presumably need to call swift functions from our compiled swift binaries from C (or directly from Java, the result being the same). Is there a way to demangle certain symbols in the output binary to this effect, or is there another / a better way to access Swift functions from C? 
> > 
> > Others can probably give a more detailed response, but... 
> > 
> > There’s a Swift demangler in Swift’s “Basic” library (lib/Basic/Demangle.cpp), along with a standalone tool (swift-demangle) you can experiment with. The information in the mangled name should be complete enough to call, but you’ll need to match Swift’s calling convention. 
> > 
> > If it’s just a specific set of Swift functions you want to call from C, you can use the @_silgen_name attribute to override the mangled name, and/or make them @convention(c) to use the C calling convention. 
> 
> @_silgen_name isn't the right answer here, since the convention will be wrong, and it won't interact properly with Clang imports and exports. Like Slava said, you want something like the '@_cdecl' attribute he proposed and I half-implemented. 
> 
> -Joe
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20151211/166e2560/attachment.html>