[hellogcc] Re: [hellogcc] Re: [hellogcc] Re: [hellogcc] Re: [hellogcc] Re: [hellogcc] Re: [hellogcc] 新听说一个 cosy compiler
- From: Liu <proljc@xxxxxxxxx>
- To: hellogcc@xxxxxxxxxxxxx
- Date: Thu, 11 Aug 2011 10:37:40 +0800
2011/8/11 Triple Yang <triple.yang@xxxxxxxxx>:
> 你反复提到“肯定没戏”是主观臆断的。我最开始提到“cosy是帮助开发者实现一个狭义编译器的工具软件”，它的存在是为了设计编译器。cosy本身不是传统意义上的高级语言开发编译器。它的产品里边包含一个现成的C前端（我猜应该还有其它语言前端，为了方便编译器的开发）。这就是说，从可能性看，你可以用cosy重新设计一个和gcc完全兼容的编译器。（当然这件事情非常之复杂和没有意义，所以几乎不可能。）
这个是我亲自测试的结果！！！不要理论上，理论上，我要的是实际中能做出来可靠的产品的！
>
> glibc是C标准库的一个扩展，但是一个设计良好的语言支持库不应该依赖于编译器（当然我们也可以把其中依赖的部分剥去，或者重写，这就是“移植”）。此外如果“复杂”的意思是：包含非常多的功能部分，彼此之间紧密联系，glibc就不能称为复杂（相对于操作系统，编译器，数据库等），窃以为“庞大”更为合适。
What ever glibc是存在的，并且是事实上的标准。你可以不承认，但是事实就是这样的。
>
> 我更倾向于从可能性上看待对一个工具的评估，所以有上面的观点。
I don't care 什么可能性，我只关心能不能交付给用户一个可靠的产品。
> LLVM目前还不是一个完整的工具链，它很多子项目还处于开发中。它漂亮的地方在于一个架构良好的C/C++前端，比之gcc十几年来的积累的大量冗长代码要易于理解和管理，接口也设计得更好。在苹果操作系统中，官方配置是有llvm前端和gcc后端以及其它gnu工具配合使用的例子，在其它操作系统中没有听说过。
clang+gccBE？这个绝对没有。绝对没有。我非常清楚，清楚到跟Apple
Team的人一起聊天的清楚，清楚到我自己也移植维护了一套LLVM的Toolchain。
LLVM已经比较完整了，难道除了GNU Toolchain还有比LLVM完整的开源Toolchian？我不知道哎。
子项目是子项目，但是不代表没有其他的项目可用，你不能用，那是没有做必要的移植和开发工作。我们就提供GNU和LLVM两套Toolchian。
子项目，首先是有子项目，有，就代表有可能成长起来，比起来那些什么都没有的强的不知道多少倍了。关键是LLVM社区是活跃的，活跃的。
>
> 我觉得不出意外的话，llvm将会大火。
>
> 2011/8/10 Liu <proljc@xxxxxxxxx>
>>
>> 2011/8/10 Triple Yang <triple.yang@xxxxxxxxx>:
>> >
>> > 从功能上说，as和ld是“广义”编译器的一个部分。一个“狭义”编译器只能把高级语言翻译成汇编。比如说，我们从gcc官网上下载的源码包是一个狭义编译器，as和ld包含在另一个工具集binutils中。
>> >
>> >
>> > 在工具软件开发者看来，汇编器和编译器可以没有任何直接的关系。一般是处理器设计者定义了指令集（包含相应的助记符）的文档，汇编器根据该文档在支持该指令集的基础上，会有一些高级的扩展功能（如label，宏汇编等等）。狭义编译器把高级语言翻译成助记符，其中往往也包含着一些汇编扩展功能支持的特性，这可能是编译器和汇编器最重要的联系。在这个意义上，汇编器又分为两个阶段：预处理和汇编，前者负责处理汇编扩展功能。
>> >
>> > 链接器负责目标文件的链接，它以汇编器的输入为输出，它和指令集有关的部分大概仅在于重定向。链接器主要是和目标文件格式有关。
>> >
>> > 总结起来就是：1. 狭义编译器主要是与高级语言和指令集相关，但它生成助记符时需要了解汇编器对扩展功能的支持，否则可能需要加入一次汇编预处理；2.
>> > 汇编器主要是与指令集和目标文件格式有关；3. 链接器主要是与指令集和目标文件有关。
>> >
>> > 现在几乎没有高度耦合的“广义”编译器存在，这些功能部件都是分开的。从底层到高层看，是汇编器对编译器提供下层支持，而不是反过来。
>> >
>> 科普的不错。
>> > 在上面的基础上，我回答你的问题：
>> > 1.
>> >
>> > cosy是帮助开发者实现一个狭义编译器的工具软件，自然不包含as和ld，因为这两个功能部件是和处理器密切相关的底层软件，它们更多的是与处理器设计相关（许多处理器设计软件支持自动生成可用的汇编器和链接器，但是自动生成编译器比较困难，大概还没有实际用途）。
>> >
>> 就是说没有自己的AS和LD。
>> > 2. cosy支持全部c90和大部分的c99特性，所以在一个合理移植的C语言（标准以及适当扩展的）库的基础上，编译linux
>> > kernel应该没有问题，根本的限制大概在于硬件是否支持全部的操作系统特性（如内存分页等）。
>> >
>> 这个肯定没戏，是肯定没戏，肯定没戏。
>> > 3. 如果内核可以编译，广大的应用软件应该没有原则上的困难，只是一个工程实践转化为现实性的过程。
>> >
>> 这个没戏，还是没戏，没戏。glibc那不是一般的复杂，QT里面C++的特性发挥得淋漓尽致。
>> > （咿呀呀，写了好多！）
>> 看来工作中靠谱的toolchian只有GNU和LLVM。
>> > 2011/8/10 Liu <proljc@xxxxxxxxx>
>> >>
>> >> 2011/8/8 Triple Yang <triple.yang@xxxxxxxxx>:
>> >> > 是一种compiler designer, 卖得好贵的，试用过oem的express版本，不错。老欧洲几十年的积累不是随便盖的。
>> >> AS和LD也是他们自己的么？
>> >> 兼容gcc程度如何？
>> >> 能不能编译出来运行正确的Linux Kernel，GNU Libc，Xorg，QT/GTK，KDE/Gnome等广大人民群众使用的软件啊？。
>> >> >
>> >> > 2011/8/8 Liu <proljc@xxxxxxxxx>
>> >> >>
>> >> >> http://www.ace.nl/
>> >> >>
>> >> >
>> >> >
>> >
>> >
>
>
Other related posts:
