Comments

cool, i love it!!!
daniel

well, despites both popularity and availlability, gcc is actually the whorst compiler money can "buy" and here is why:

1. it's very buggy (despites the common source tree, many bugs bubble in both front and back ends)
2. it's very slow (talking about compile time)
3. the level of optimization is very low (slow is bad, fast is good)
4. it's false compliant (claiming you are 100% ansi compatible is definitely an exageration, mainly because the standard itself is over 5% ambiguous!)
5. most of the source dates from 20 years ago and it suffers from so many syndroms, i would need 20gigs to log a full analysis...)
6. it lacks crucial options big time! e.g. consistent allignment, etc - to add insult to the injury, each platform adds its own inconsistencies...

regards,
daniel.

KSG wrote:

Have you tried to add a pass to gcc before?  Phoenix is made to be modular and understandable so that researchers can do research with it (Notice that despite gcc being open source and free, no one uses it in research?  Do you know why?).

Also Phoenix is so configurable it can be used as a JIT, and is the basis for tools, such as binary rewriting or static checking of source code.  Things that gcc can not do.

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

of course, who would do fundamental compiler research on existing/production compilers? do you know any universities using msvc++ for compiler research? anyway, few gcc links (generic research) including stanford, princeton, mit, harvard, etc... using gcc for more or less compiler related research... it's really different from production environments and here is why:

class 1. when you do compiler research for a company, you have deadlines, competitors, major compiler optimisations and language features comming from marketing

class 2. when you do compiler research for an university, you have to make sure your students get teh basics, a strong fundation of generic compiler axiomes and so on, you couldn't care less about optimisations, etc

so, when you said "Notice that despite gcc being open source and free, no one uses it in research?  Do you know why?" my answer is simple, here is why:

class 1. because they have to ship their own compilers, because they compete with gcc, etc

class 2. because gcc is a PRODUCTION COMPILER and not a DIDACTIC COMPILER... of course, i have absolutely no reason to believe that someone could actually do any kind of fundamental compiler research using a compiler which only comes on binary form...


my2c, in good faith, of course!
d

http://gcc.gnu.org/readings.html
http://suif.stanford.edu/suif/mlists/suif-talk/199408/19940812.html
http://suif.stanford.edu/collective/
http://www.stanford.edu/class/cs195/materials/asgns/asgn1/asgn1.pdf
http://www.cse.msu.edu/~dengmin1/research.html
http://www.intel.com/research/mrl/news/files/MRFKeynote_Compiler.pdf
http://www.princeton.edu/~wqin/build.htm
http://www.princeton.edu/~xzhu/mips.html
http://www.princeton.edu/~raas/beowulf/Software.shtml
http://www.mit.edu/afs/sipb/project/gcc-3.4/
http://www.cs.rhul.ac.uk/research/languages/projects/rdp.shtml
http://gcc.gnu.org/ml/gcc/1997-11/msg00773.html
http://opensource.mimos.my/fosscon2003cd/paper/slides/18_nur_hussein.pdf
http://216.239.57.104/search?q=cache:1JjWvwyUC1UJ:finiteloop.org/~btaylor/etc/bret_taylor-resume.pdf+gcc+research+stanford&hl=en

KSG wrote:

Have you tried to add a pass to gcc before?  Phoenix is made to be modular and understandable so that researchers can do research with it (Notice that despite gcc being open source and free, no one uses it in research?  Do you know why?).

Also Phoenix is so configurable it can be used as a JIT, and is the basis for tools, such as binary rewriting or static checking of source code.  Things that gcc can not do.

Thanks,

Kang Su Gatlin
Visual C++ Program Manager

[quote user="KSG"]Notice that despite gcc being open source and free, no one uses it in research?  Do you know why?).

No, because they actually do so, following link for starters:

http://gcc.gnu.org/readings.html

Re(1): sure we do... i asked you q1 because jits cannot optimize at the level of a "static" compiler

Re(2): :-)2

Re(3): same here...

Re("Hope that helps."):Oh ya!

Thanks,
Daniel

Hi Kang,

I have a quick question for you (since you are the product manager for c++):

Q: Are you in feature complete mode with the new (2005) c++ language extensions and compiler driver?

So, is the compiler frontend frozen? Knowing how you work (from the past) I'd say you should be in bug fixing mode... But I'd like to get a confirmation from you.

PS
We call cl by the "compiler driver"... I was refering to the options cl exposes...

Thanks & Regards,
Daniel

well... maybe it's 1.0... but with sooooo maaany service packs lol

ps
i'd like to send you a link to "the seattle times" - october the 28th 2009... (ms, the first windows and unix provider for homo sapiens sapiens 1.0 sp 6009) but nah, cause the link would be broken for anohter 5 years...

nice post!
daniel

hi there,

i'm a pilot too... not flying a 747 like you guys, but still...

now, that you mentioned about us expressing our wishes in the open, i will send you my first one...

i would like to know how could a compiler engineer (obviously not working for Microsoft) have access to (let's say, something cool like) Phoenix source code (or at least interfaces), under nda, at evening time. is this possible? does one have to sign an nda for that? does one have to get more rain for something like that to happen? the question is as simple as the purpose (getting closer to the common backend, you can hook more frontends into Phoenix, in a completely open and proactive manner...) which should sound good to you too... more supported languages, more outstanding tools, healthier the platform, etc...

ps
i heard alot of voices like "oh, this is cool" or "this rocks"... but i am trying to see if this site goes beyond having a nice chit-chat with happy passangers my 7 years from Home sound more like "hey, we have work to do!" so... can we do it or not... // just my 2c...

regards,
daniel

Quick question. I'm wondering about the time-frame when 3rd party compiler manufacturers are going to benefit from Phoenix. I understand that the backend interface(s) will be relatively public.

Also, I suspect that the linker itself will not need any changes at all (that's the whole catch, right? why maintaining 2 linkers (one for c# & vb and another for c++) instead of one...) - so, implicitly, tools manufacturer companies which already purchased deployment priviledges for the c++ toolchain (compiler, resource compiler, librarian, linker, etc) should be able to deploy the linker with Phoenix... Is this right?

If my questions go beyond the scope of this area, please accept my appologizes.

Thanks,
Daniel

one word: SUPER!!!


ps
you call the new c++ language extensions by "managed code extensions, 2002 and 2003". i am aware of stroustroup "apetite" of improving the c++ language definition (in the ansi comitee). telling stroustroup that c++ doesn't have enough rtti, that it doesn't have support for true properties and events is like selling fridges to eschimoes... now, trying to avoid entering in more politics about the ansi comitee, i would like to propose you something:

1. instead of calling your c++ language extensions by "managed code extensions" just call them simply by "c++ language extensions" especially now, when you will be able to use the new c++ extended dialect to generate native code as well.
2. standardize them asap via ecma. ansi will not adopt them (mostly because ansi is 99.999% politics instead of trying to properly innovate the c++ language for the benefit of the many)
3. instead of trying to reach the less common denominator among language family members, try to increase the level of abstraction to each language. (e.g. instead of reducing the "managed" c++ operators overloading capabilities to the level of overrideable operators from vb or c#, make c# and vb capable of overriding (almost) everything...) you already started this path (e.g. read "c# generics") but there is more to come...

good luke & best regards, yours,
daniel // sc*tts v*ll*y