RTEMS 为什么必须使用GNU的工具链开发？

很多朋友问我这个问题，也抱怨GNU工具链不如集成开发环境好用。如IAR Workbench、Keil、RVDS等。并不理解，为什么RTEMS死磕GNU的工具链。这里其实有很多原因，有一些是我猜测的，有一些是既定的事实。下面就聊聊这些原因：

1. 首先，RTEMS 从上个世纪80年代末开始开发。那时候，还没有这么牛叉的集成开发环境；GNU的工具链应该是当时不二的选择。

2. RTEMS作为一个开源免费的操作系统，面对很多问题；最重要的一个点就是真正的免费开源。大家都知道，集成的开发环境是昂贵的，集成开发环境也是一套非常完善的软件系统，无论RTEMS自己投入精力去开发，还是借用别人的嫁衣。都是一个不菲的投入。为了更好的发展，GNU也是最好的选择。

3.GNU工具链支持的平台丰富，这个是世界上任何一个编译器都无法匹敌的。提供一致性的开发风格和调试方法。RTEMS 在这个编译平台下，才能茁壮发展。IAR 公司的确提供了很多编译器，有ARM、430、PIC、51等等，但相对于GNU来说，小儿科也略显稚嫩。我曾用过IAR EWARM做过开发，几乎每个版本都有BUG，编译器自身的Bug。GNU的编译器GCC相对成熟很多。当然，某些专业领域可能比不上某些编译器，如RVDS、Keil等，但也绝对有得一拼。这是开源世界奉献的精华！

我想这两个原因是足够的了。很多朋友想能不能把RTEMS移植到相关的开发环境下呢？

这个问题相对比较复杂，由于RTEMS从一开始就在GNU上开发，其实很难做这种移植了。主要有以下几个问题：
1.RTEMS 的库使用的是newlib,此库是用GNU工具链开发的，因此需要GNU编译，如果移植到别的平台上，首先要解决newlib的移植问题；

2.RTEMS 的C语言部分，有些地方采用了GNU的特殊编译指令和扩展，需要移植，并不是所有的C编译器都支持这样的命令和扩展，可能产生无法兼容的效果，而不得不修改代码。这对普通用户来讲，是比较难解决的问题。

3.RTEMS 的编译和配置是依赖于make和configure，这个是最大的问题，自己将文件加入工程中，可不是一件轻松的事情。必须要仔细阅读Makefile和configure，这两个文件是通过automake和autoconf实现的，并不是那么好解决这个问题。

4.RTEMS 内部的一些移植和实现高度的依赖于GCC，这个是没有办法的事情。比如说内存屏障，在一些特殊CPU上的寄存器保护等等。源代码比较难懂，别的编译平台上大都没有类似的东西。比如说arm gcc和iar ewarm编译器使用寄存器的策略就差得比较远，以至于一些实现上差得也比较远。

最后，RTEMS不同于FreeRTOS,uC/OS-II这种小麻雀，他提供了立体的操作系统的逻辑和框架；如C++的支持，还有其他编程语言的支持，我看wiki上扬言要支持parrot。别以为FreeRTOS和uC/OS-II也能支持C++，不是这样的。RTEMS的支持，是从核心的支持；C++的全局构造函数要求先于main函数之前执行，FreeRTOS、uC/OS-II都是做不到的，因为main函数之前，可能操作系统的核心还未初始化呢!这是RTEMS与他们的最大的一个不同。虽然通过技巧也可以再FreeRTOS和uC/OS-II上实现，但与RTEMS比，效果要打折扣的。

简单的聊聊，希望纠结的朋友不要再纠结，其实GNU的工具链很好用；用熟了，其实它的高效会让你爱不释手！