编译器执行效果

⑴ 有关单片机编译器的问题

51、AVR、PIC、ARM、MSP430、SPCA61等单片机，因为它们的CPU构架不同，所以所使用的机器语言的定义就不同了，也就是对应于使用的汇编语言的不同。在使用C语言设计程序时，对于不同的单片机，其C源码可能都相同，但通过不同的编译器，生成的机器代码会是天壤之别，例如对于一个查找数组中最大值和最小值的C程序，8MHz的AVR单片机执行效果相当于200MHz的89C51！并且二者机器代码的长度都不相同。

使用C编写程序是为了考虑兼容性和可移植性的问题，对于不同的单片机，因为构架的不同，就需要对应的编译器去解释C代码，使之能正确的控制单片机运行。

⑵ java使用JIT编译器，执行效率与C++相比哪个

我猜测：JAVA即使编译成机器码，其执行效率也不如C++的。
从整体来看，JAVA有一些需要额外的消耗是C++没有的，比如：内存回收、反射、数组越界判断等。
内存回收这一机制要求编译后的执行文件除了我们自己写的逻辑之外，还要有一个线程来管理内存。
反射一方面要有一块内存用来做类型字典，另一方面又要对反射调用做安全检查。
……
另外，如果JIT编译之后仍然有类加载器这类的东西，那么这个程序就还要内部集成一个.class文件到机器指令的解释器或编译器。
……
总之，JIT编译后的文件不得不为JAVA自身的复杂性增加一系列机制在里面，但C++的文件除了我们自己写的逻辑和本地可执行文件头之外就什么都没有了。

⑶ 编译器有什么用

简单讲，编译器就是将“一种语言（通常为高级语言）”翻译为“另一种语言（通常为低级语言）”的程序。一个现代编译器的主要工作流程：源代码 (source code) → 预处理器 (preprocessor) → 编译器 (compiler) → 目标代码 (object code) → 链接器(Linker) → 可执行程序 (executables)
高级计算机语言便于人编写，阅读交流，维护。机器语言是计算机能直接解读、运行的。编译器将汇编或高级计算机语言源程序（Source program）作为输入，翻译成目标语言（Target language）机器代码的等价程序。源代码一般为高级语言 (High-level language)， 如Pascal、C、C++、Java、汉语编程等或汇编语言，而目标则是机器语言的目标代码（Object code），有时也称作机器代码（Machine code）。
对于C#、VB等高级语言而言，此时编译器完成的功能是把源码（SourceCode）编译成通用中间语言（MSIL/CIL）的字节码（ByteCode）。最后运行的时候通过通用语言运行库的转换，编程最终可以被CPU直接计算的机器码（NativeCode）。

⑷ 编译器具体实现中比较巧妙的思想有哪些

这种做法的好处是：
可以作为解释器性能升级的一个简单路径，写解释器的代码而得到初级编译器的性能。事实上JamVM的解释器可以配置为多种实现方式：switch-threading、indirect-threading、direct-threading、inline-threading，它们的差别仅在于对opcode的dispatch方式不同；所有实现方式都共享同一份handler代码。
这种做法的缺点是：
这样写得到的“编译器”无论从代码组织还是程序思路都还是解释器的那套，从编译器的角度看很别扭。它最终实现出来效果跟从编译器角度出发的template-based JIT一样，但我觉得后者的思路更直观，代码也通常更清晰一些。
这种做法仍然无法跨越字节码边界做任何优化，因为每个opcode对应一个单独的handler，而这种做法的代码生成仅仅是把handler拷贝到一起而已。
要在它的基础之上进一步提高性能可以直接对字节码序列做些简单模式匹配，以便跨越字节码边界做优化。但这样做通常是自讨苦吃，工程上很难持续下去。

⑸ C语言同一段代码，同样的文件，编译器为什么运行结果不一样

有如下几种可能：
1 代码运行的平台硬件不同。
不同的CPU，如嵌入式CPU，intel CPU，以及IBM的CPU，在硬件最底层就是不同的，而C语言是一门和底层相关性极大的语言，在不同的硬件上运行出不同结果是很正常的。

2 代码运行的系统不同。
相同CPU在不同操作系统上跑相同代码时，一样会出现不同的结果。这是由于系统底层的实现不同造成的。比如Linux和Windows，在底层处理上就有一定的差异。

3 编译器不同，同时代码中使用了C规范未定义规则的语句。
C语言规范并没有对C语言的所有行为做定义，所以相同语句，不同编译器的运行效果可能有所不同。比如同样的sizeof(int)，在16位编译器上结果为2，而32位编译器上就会是4。

4 代码获取到的外部数据不同。
比如运行代码时获取到的其它输入不同，包括程序中获取的环境变量，实时信息，以及各种外部输入等，均有可能出现不同。
比如在做随机数时，如果以当前时间设定随机数种子，由于每次的时间是不同的，同一个程序每次运行的结果都是不同的。

⑹ 编译器和解释器的主要区别是什么他们相对于对方各自的优点

解释器
是
解释执行
的源代码，
编译器
是将源代码编译成
目标代码
他们最大的区别是程序运行时需要解释器边解释边执行，而编译器则在运行时是完全不需要的
解释器的优点是比较容易让用户实现自己跨平台的代码，比如java，php等，同一套代码可以在
几乎所有的
操作系统上执行，而无需根据操作系统做修改；
编译器的目的就是生成目标代码再由连接器生成可执行的
机器码
，这样的话需要根据不同的操作系统编制代码，虽然有像Qt这样的源代码级跨平台的编程工具库，但在不同的平台上仍然需要重新编译连接成可执行文件，但其执行效率要远远高于解释运行的程序。
编译器是把源程序的每一条语句都编译成机器语言,并保存成二进制文件,这样运行时计算机可以直接以机器语言来运行此程序,速度很快;
而解释器则是只在执行程序时,才一条一条的解释成机器语言给计算机来执行,所以运行速度是不如编译后的程序运行的快的.
这是因为计算机不能直接认识并执行我们写的语句,它只能认识机器语言(是二进制的形式)

⑺ Intel C++ Compiler与gcc对比有什么优缺点

icc 是Intel公司专门为Wintel平台设计，有针对性的做了优化，缺陷也很显然，既然有针对性，也就不具备通用性。使用icc编译，可能会使编译出来的程序有更好的执行效率，但也可能使其在非Intel CPU上运行异常。并且，在某些情况下，即使在Wintel平台上也会崩溃。
gcc的优势在于其通用性，目前主流的所有平台，它基本上都支持。使用-O3优化编译后的执行效率，也不错。
在Win平台上，编译后执行效率最好的，依然是微软的vs，这可能与win系统是他们家出的有关。
使用icc带来的优势，并不突出，还是建议不要用了。
如果限定在win平台上开发，使用vc或gcc更合适一些。我个人推荐gcc，vc的ide环境过于庞大，不太喜欢，但win平台上主流的c开发工具还是vc，有不少开源的工程都使用它，如果你用到了这些开源代码，就不得不用了。

⑻ 什么是“编译器”

了解的C/C++编译器如下：
GCC家族有
Cygwin
Mingw32
DJGPP
Dev-C++(Mingw32)
还有正宗的GNU GCC 2.95.5~3.0.0.4版本
MS家族有
MSC 5.0、6.0、7.0
MSQC 1.0、2.5
MSVC 1.0、4.2、6.0、7.0
Borland家族有
TC 1.0、2.0
TC++ 1.01、3.0
BC 3.0、3.1、4.0、4.5、5.0、5.02
BCB 3.0、5.0、6.0
其它有
Intel C/C++ 5.0
Watcom C/C++ 11.0、11.0c
VectorC 1.3.3
IBM VisualAge for C++
DigitalMars C/C++
KAI C/C++ 4.03f for RedHat 7.2
Lcc4.1
LCC-WIN32 2001-09-25~2002-04-28日版
Small C
CC386
Pacific C
另外还有C的解释器
Quincy
Eic
CINT

上面提到的编译器/解释器，大部分我都使用过。现在固定使用VC7.0 Cygwin Mingw32 VectorC和LCC-WIN32这五种编译器。

在GCC家族中GNU GCC是根本，其它的编译器版本都是从它导出的。其中，Cygwin和Mingw32都是WIN32平台下的编译器，DJGPP是DOS下的32位编译器。大家所熟知的DEV-C++充其量只是GCC的一个外壳，它所自带的编译器就是Mingw32的一个版本。这些GCC的版本中，Cygwin是最大的，它与其说是一个编译器，倒不如说是一套编程工具。它不仅有编译器，还有其它很多的工具。其实，它就是一个UNIX系统在WIN32平台上的实现。实现了大多常用的UNIX工具，最近的版本中连Apache这样的“工具”都集成进来的。不过，Cygwin虽然功能强大，但它却不是很易用（和UNIX相似，熟悉UNIX的人用它可以很快上手），因为太多其它的工具分散了人们的注意力。相比之下Mingw32就要好用得多，它只有最基本的几个编程工具（只可惜它不自带GDB）。GCC中并不只是C/C++编译器，其中还有很多其它的编译器如JAVA，Fortran，ADA等。它是一个编译器集合，不过有些编译器只能在UNIX系统上用。MS家族的编译器就不用说了，大家对它们都很熟悉。VC 7.0(VC.NET)是它的最新产品。Borland家族也不用说，大家也是耳熟能详。最近它才推出了BCB 6.0。

其它的编译器如：Intel C/C++大家一看名称就知道是Intel的东西，它和VC6完全兼容，不过要挂在VC6下才能用。Watcom C/C++是早先编译器四国大战中的一员，原本是很不错的东西，可惜战略不对，现在已不见声息了。倒是以它为基础的一个OpenWatcom现在还在奋战。VectorC是我近日才发现的一个好东东，它是个纯C的编译器。IBM的VisualAge for C++原本是IBM想用来淌C++编译器这片浑水的东西，不过IBM的战略改了，它就被放弃了。DigitalMars C/C++的前身的Symantec C++（它也是编译器四国大战中的一员），不过现在Symantec不做了，于是它的作者就把它改成了DigitalMars C/C++开放给大家使用。以上这些都是WIN32平台上的东西。KAI C/C++是个很强大的C/C++编译器，它是个多平台的编译器。不过现在被INTEL收购了，已经停止开发了。Lcc4.1是个纯C的编译器它是开放源代码的。不过不怎么好用。LCC-WIN32是一个在LCC基础上开发的C语言的集成开发环境，很好用，而且有很详细的资料，FREE！Pacific C是一个纯DOS的C的集成开发环境，就不多说了。Small C CC386都是开放源代码的编译器，它们都很简单，应用来给大家学习编译器的。Quincy Eic CINT都是C的解释器，是用来让大家学习C语言的其中CINT的功能很强大，还支持一些C++的特性。
当然还有很多其它的编译器，这里我给出的编译器都是可以在WIN32或DOS平台上用的（除KAI外）。UNIX平台上的编译器还是以GNU的为主，其它的我就不是很清楚了。

在以上的编译器中，最特别的就是VectorC这个东西只支持纯C。但它却号称是最快的编译器，不过经过我的试验，它的确在有些情况下强过其它编译器很多！而且它还有个交互式的优化器，可以让你直接看到C代码对映的汇编代码。Cygwin和Mingw32为一母所生，其运行效果相差不大。它们生成的代码效率都很不错，编译的速度也很快，最值得一提的是它们对C++的特性的支持算是所有编译器中最完全的，而且它们还支持C99的大部分特性。这一点很是不错！大家对MS的VC已经很熟悉了，本不用我多说。不过在它的最新的产品VC7.0中，有很大的改进。它对C++的特性的支持比6.0有了很大的提高，是我所用的编译器中是仅次于GCC的。而且它编译出的程序，运行速度很快！仅有少数时候次于VectorC与GCC，其它情况都是最快的！其平均运行速度是最快的。对Borland的产品我也无需多说。它的TC2.0与BC3.1都是我最喜欢的东西。可是现在的BCB却大不如前了，编译的速度和VC6一样慢！IDE还有较多的BUG。最令人想不通的是它生成的代码的运行速度很慢，比LCC-WIN32还慢！它唯一值得一提的就是它的RAD做的比MS的好。Intel的编译器大家可能不熟，它太贵了！还要有VC的支持，很不划算，而且编译速度比VC6还慢。不过它的代码质量很不错。DigitalMars C/C++没有什么亮点，编译速度较快，代码执行速度适中，对C++特性支持还算不错。LCC-WIN32是个很不错的集成开发环境，它只支持纯C。它的编译速度极快！代码执行速度较慢。不过它的最大亮点在于它的IDE，在所有的FREE编程工具中，它的IDE是最专业的，有很强大的代码分析，管理功能。而且它提供了大量的编程资料。
我曾对一些编译器的代码执行效率做过一些测试，以下是概况：
1. VectorC、VC 7.0 （极快）
2. Intel C/C++、VC 6.0、GCC （很快）
3. DigitalMars C/C++ （一般）
4. LCC-WIN32、BCB、BC5.02 (较慢)
当然，我所做的测试比较片面。不过在很大程度上已能反映其大概状况。

⑼ Clang 比 GCC 编译器好在哪里

编译速度更快、编译产出更小、出错提示更友好。尤其是在比较极端的情况下。

两年多前曾经写过一个Scheme解释器，词法分析和语法解析部分大约2000行，用的是Boost.Spirit——一个重度依赖C++模版元编程的框架。当时用g++ 4.2编译的情况是：

编译速度极慢：完整编译一次需要20分钟

编译过程中内存消耗极大：单个g++实例内存峰值消耗超过1G
中间产出物极大：编译出的所有.o文件加在一起大约1~2G，debug链接产物超过200M
编译错误极其难以理解：编译错误经常长达几十K，基本不可读，最要命的是编译错误经常会长到被g++截断，看不到真正出错的位置，基本上只能靠裸看代码来调试
这里先不论我使用Spirit的方式是不是有问题，或者Spirit框架自身的问题。我当时因为实在忍受不了g++，转而尝试clang。当时用的是clang 2.8，刚刚可以完整编译Boost，效果让我很满意：
编译速度有显着提升，记得大约是g++的1/3或1/4
编译过程中的内存消耗差别好像不大
中间产出物及最终链接产物，记得也是g++的1/3或1/4
相较于g++，编译错误可读性有所飞跃，至少不会出现编译错误过长被截断的问题了
当时最大的缺点是clang编译出的可执行文件无法用gdb调试，需要用调试器的时候还得用g++再编译一遍。不过这个问题后来解决了，我不知道是clang支持了gdb还是gdb支持了clang。至少我当前在Ubuntu下用clang 3.0编译出的二进制文件已经可以顺利用gdb调试了。

最后一点，其他同学也有讲到，就是Clang采用的是BSD协议。这是苹果资助LLVM、FreeBSD淘汰GCC换用Clang的一个重要原因。
答案出自：http://www.hu.com/question/20235742