Ask HN: Is it feasible to port Apple's Swift to the ESP8266? | Hacker News Reader

Ask HN: Is it feasible to port Apple's Swift to the ESP8266?

3 pointsschappim17 comments

Is it feasible to port Apple's Swift to the ESP8266?

What would be involved?

Does the fact that it's so intertwined with LLVM make a difference? Or is it just a case of writing a new interpreter, and the LLVM-ness doesn't really make a difference.

I'm a simple web programmer and out of my depth here.

I'm posting this off the back of reading the HN post on "A Kickstarter for funding Micropython port to ESP8266"[1].

[1] https://news.ycombinator.com/item?id=10993953

View on HN

One would have to write an Xtensa lx106 backend for LLVM. Given that this architecture is pretty simple, just another typical RISC, it should be possible to rewrite, say, a MIPS backend instead of starting from scratch. I'd say it's about a month of a part-time work for a single developer.

Awesome thanks!

Swift is not an interpreted language, AFAIK.

So you mostly need an LLVM backend for your microcontroller. It might even exist already.

That has almost nothing in common with the MicroPython situation.

Swift can be interpreted in it's repl.[1]

[1] https://developer.apple.com/swift/blog/?id=18

REPL is not an "interpreter" in any way. These are orthogonal concepts.

Not that orthogonal...

Like Python, Swift's interpreter is also it's repl. See: http://dev.iachieved.it/iachievedit/using-swift-as-a-scripti...

REPL is not an interpreter. 'E' in REPL does not imply any particular execution mode. It can be anything - direct interpretation, mixed mode (compilation + VM interpretation), native compilation - whatever.

And, also, the notion of 'scripting' is orthogonal to these two. It got nothing to do with both a REPL functionality and interpretation. Scripting is a mode of using a language, not a runtime semantics.

All I'm saying is the same binary is acting as the interpreter and REPL for swift and Python, this is different to other languages. A good example is Ruby which has it's repl as a seperate binary 'irb'.

There is no interpreter for Swift. At least not yet.

Am I missing something from this article:

https://medium.com/swift-programming/1-learn-swift-by-runnin...

Yes, unfortunately, there are far too many people who do not care about using correct terminology.

Also just so I know I'm not going mad: https://www.google.com/#q=%22the+swift+interpreter%22

If /usr/bin/swiftc is the "swift compiler" what would you call the binary: /usr/bin/swift ?

To answer my own question:

"swift" or "swiftc" w/o -frontend invokes the driver, which launches both the -frontend and other tools like ld.

The Swift REPL (Read-Eval-Print-Loop) acts like an interpreter. Valid statements, expressions, and declarations are immediately compiled and executed.

It is a Swift REPL. Do not confuse REPL with an interpreter.

sklogic is right.

You would want an xtensa llvm back end first. The biggest issue I think would be the lack of available ram. Micropython is written from scratch to be very focussed on being very small and uses a simplistic trace garbage collector whereas swift uses reference counting that tends to need more ram and more CPU. Possible but unlikely to be practical.

Reply on news.ycombinator.com