swift 是先翻译成 Objctive-C 代码再 c 再汇编在 01？

看到篇文章如下

CocoaChina 上的 xu54 认为 Swift 本质其实就是 Objective-C 的文本变种，对于这门全新的语言，苹果做的工作其实远没有我们想像的艰巨。 LLVM 编译器做工作只是先把 Swift 翻译成 Objective-C 代码，然后再把 Objective-C 代码翻译成 C 语言代码，然后再把 C 语言代码翻译成汇编，最终翻译成机器码。至于为什么编译器厂商这么绕，不直接把自己的语言翻译成汇编和机器码，那是由于现有的语言编译器（ Objective-C 、 C )已经非常成熟，而高级语言间的文本转换开发成本和维护成本都极其小。 Swift 之所以要翻译成 Objective-C ，是由于 Swift 仍然需要 Objective-C 中的 ARC 、 GCD 等环境。既然 Swift 其实就是 Objective-C ，对入门者而言远比 Objective-C 好学，对资深开发者来说又能节约很多无谓的低级重复的机械代码（这些代码在 LLVM 翻译成 Objective-C 时，编译器自动帮你写上），并且开发者关注的应该是业务逻辑，而不把精力分散在语法等低级问题上，语法消耗的时间越少，这门语言也就越成功，所以他觉得 Swift 必定会替代 Objective-C 。

感觉不对劲啊………………………………………意义何在…为什么…

Swift

编译器

翻译

代码

22 条回复 • 2015-10-15 02:22:48 +08:00

sherlocktheplant

2015-10-14 01:01:17 +08:00

应该不会有这么蠢的设计 swift 作者就是 llvm 最初的作者

Ixizi

2015-10-14 01:08:47 +08:00

@sherlocktheplant 别应该啊 … 郁闷

ipconfiger

2015-10-14 01:14:24 +08:00

胡扯！

Perry

2015-10-14 01:16:39 +08:00 via iPhone

并不关心，反自己用着舒服就可以了

msg7086

2015-10-14 01:33:29 +08:00

你说反了。明明有现成的编译器组件，为何还要从头重写一遍？

GCC 也好 LLVM 也好，都是分前后端，先转码成一种中间形态，然后再转译成汇编和机器码的。

如果 Swift 是 Obj-C 的一个变种环境，那么做成 Swift -> Obj-C -> 汇编我不觉得有什么不妥。

rainex

2015-10-14 02:29:32 +08:00

@sherlocktheplant
是不是这种搞法没细看，但这搞法倒也有先例， C++ Builder 就是先把代码翻译成 Pascal ，用成熟的 Delphi 编译器来生成 Windows 的可执行代码，估计还是有时间和维护成本的问题，不然要说做写编译器，当时 Borland 公司里可是一帮好手，未必比 Apple 弱。

@msg7086
缺点还是有的，多转换一步肯定要慢一点，除非代码量少， C++ Builder 的用户为这个没少骂。

因为这话题，又想起 Anders Hejlsberg 来了，真是个天才。

msg7086

2015-10-14 02:32:57 +08:00

@rainex 嗯，基于成本考虑的话多一步比较便宜。基于性能考虑的话少一步比较快。

dorentus

2015-10-14 08:43:58 +08:00 via iPhone

Swift 一堆 Objective-C 无法支持的特性和数据结构，怎么先编译成 Objective-C ……

jiyee

2015-10-14 09:17:04 +08:00

如果成立，那 iOS 7 为啥不能用...

wxl1380610

2015-10-14 09:21:44 +08:00

@jiyee 好有道理

sherlocktheplant

2015-10-14 09:34:28 +08:00

@Ixizi
我反正搜了很多资料都没提到 swift 编译成 objective-c 的

sherlocktheplant

2015-10-14 09:38:23 +08:00

@rainex
@Ixizi

根据这个 stackoverflow swift 是先编译成 llvm 字节码再编译成机器码只是最终是在 Objective-C 的运行环境里运行

就相当于 Groovy 、 Scala 和 Java 的关系

Ixizi

2015-10-14 09:43:42 +08:00

@sherlocktheplant 上 stackoverflow 地址..
swift 和 objective c 用的同一套 runtime?...

Ixizi

2015-10-14 09:48:00 +08:00

请教下偶像 : ) @onevcat

sherlocktheplant

2015-10-14 09:48:23 +08:00

@Ixizi http://stackoverflow.com/questions/24052386/does-swift-compile-to-native-code

sherlocktheplant

2015-10-14 09:53:42 +08:00

@rainex
@Ixizi

这里找到一篇讲详细编译过程的 swift 是编译成一种他们自己设计的中间语言 swift intermediate language 再编译成 LLVM IR 再编译成机器码
http://arstechnica.com/apple/2014/10/os-x-10-10/22/

fo2w

2015-10-14 10:30:57 +08:00

LLVM 那哥们是什么人......
他做什么我都觉得是对的....

dorentus

2015-10-14 10:33:53 +08:00

@sherlocktheplant 但其实它脱离 Objective-C runtime 也一样可以运行。

onevcat

2015-10-14 17:20:25 +08:00

@Ixizi 编译分为前端和后端，对于 Swift 来说，和 Objective-C 编译上的区别主要在前端（废话...后端的话 LLVM 能编译的语言都是一样的...）。 Swift 编译器先把 Swift 源码转换为 SIL ，就是上面 @sherlocktheplant 说的 Swift Intermediate Language 。 SIL 基本就是对 Swift AST 的组织，然后中间多了一步从 SIL 优化生成 LLVM IR 。到这里之后的后端的话，是和 objc 的处理基本是一样的，因为输入的同样是 LLVM IR 。

转换成 Objective-C 的说法简直是无稽之谈...

jiang42

2015-10-14 18:18:14 +08:00 via iPhone

@onevcat +1

cdfmr

2015-10-14 21:39:22 +08:00

@rainex BCB 在编译过程中并没有先翻译成 Pascal ，只是其使用的 RAD 库是 Pascal 语言编写的 VCL 。 BCB 编写的程序，一般由用户代码、 C++运行时、 Pascal 运行时和 VCL 这几部分链接而成，这让很多使用 C++而有优越感的人不爽，高贵的 C++居然需要其它语言编写的库来支撑，因此一直有人建议 Borland 使用 C++重写 VCL 。 BCB 编译器生成的代码运行效率不慢，真慢的话，大部分还是用户代码的原因，比如初学者滥用控件，却因不知控件内部的实现机制导致一些没必要的系统开销，非编译器之原因。

rainex

2015-10-15 02:22:48 +08:00

@cdfmr
@sherlocktheplant 我都是猜测哈，说 c++builder 和 delphi 的例子，是类比 swift 和 objc ，至于翻译，直接从一种高级语言翻译成另一种高级语言是没必要的，毕竟高级语言代码只是对人友好，对编译器没意义，先都翻译成中间代码（中间代码这个没标准，自家定义），下一步再让编译器产生可执行目标代码即可， c++ builder 里， c++项目里可以用 pascal 写的控件，可以加入用 pascal 写的 unit 代码（但我记得反过来就不行， delphi 里不认 c++builder 代码，由此可以佐证 c++builder 对 delphi 语法和编译部分的依赖，换句话说，后者成前者子集了）， swift 和 objc 的关系我觉得也类似，我理解题主所说的也是类似意思，苹果没必要把 swift 翻译成 objc 的明文，出个中间代码就行了，短平快，先让 objc 的编译技术积累发挥一些价值，将来有精力了让 swift 的编译再完备起来。