> On 6 Sep 2017, at 11:29, blaster_in_black via swift-dev <swift-dev@swift.org> > wrote: > > Hi, Alex, and thank you so much for such a throroughly reply! > > Abusing your good will, let me ask you yet another question. I understand, as > you've pointed out, that certain parts of functionality shall always be > implemented in low-level language with direct access to syscalls, such as > C/C++. Are you able to suggest me a way to find all, or at least most of > those parts? I'd like to estimate what they represent - what they build and > provide on top of syscalls and libc.
Well, one way would be to clone the https://github.com/apple/swift/ <https://github.com/apple/swift/> repository and then find out any files which end in .c or .cpp :) The problem is that there's a lot of stuff there, which means it's difficult to answer your question directly. In addition, Swift builds upon other libraries - for example, using ICU to perform the Unicode boundaries - and it's not clear where you want to draw the line. Most of the Swift infrastructure is built upon LLVM - in fact, the Swift REPL is really just an extra set of runtime functions on top of the existing LLVM/LLDB type repls (you can switch into LLDB using : in a Swift interpreter, and back to Swift with repl). LLDB in turn has Python embedded within which you can run with 'script': $ swift Welcome to Apple Swift version 4.0-dev (LLVM f53eb03c15, Clang 1757394ff0, Swift 75b7e05e20). Type :help for assistance. 1> : (lldb) script Python Interactive Interpreter. To exit, type 'quit()', 'exit()' or Ctrl-D. >>> print("Hello from Python in LLDB in Swift") Hello from Python in LLDB in Swift >>> I'm not sure what kind of 'syscalls' and 'libc' you are looking for, but you can use various tracing programs (e.g. strace, dtrace) to find out where they are being called directly, or you could run it under lldb and set various breakpoints to do the same. Finally, the resulting executable generated by a Swift compiler consists of a number of parts; information generated by the compiler and optimiser phases, calls out to external libraries (like libc or libicu), as well as calls to runtime functionality used by the Swift runtime, such as memory allocation and reference counting. There isn't a clear delineation of where those come from, so unless you want to get a little bit more specific about what you're hoping to find, you're probably best just spelunking through the codebase. Alex
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
