Форум программистов, компьютерный форум, киберфорум
Теория программирования
Войти
Регистрация
Восстановить пароль
Блоги Сообщество Поиск Заказать работу  
 
Рейтинг 4.77/35: Рейтинг темы: голосов - 35, средняя оценка - 4.77
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562

На чём пишут компиляторы?

18.04.2011, 10:25. Показов 6689. Ответов 19
Метки нет (Все метки)

Студворк — интернет-сервис помощи студентам
На чём пишут компиляторы?
0
Programming
Эксперт
39485 / 9562 / 3019
Регистрация: 12.04.2006
Сообщений: 41,671
Блог
18.04.2011, 10:25
Ответы с готовыми решениями:

На чем пишут презентационные диски?
Подскажите ПЛИЗЗЗ на чем обычно пишут презентационные диски. Причем нужно что-нибудь такое что можно было как можно быстрее это дело...

В чем пишут на C?
Ребят, в какой системе программирования пишут на чистом C?

Чем отличаются компиляторы?
Здравствуйте. 32-bit / 64-bit -- Понятно. Чем отличается threads-win32 от threads-posix, dwarf от sjlj?

19
Заблокирован
18.04.2011, 11:46
Цитата Сообщение от taras atavin Посмотреть сообщение
На чём пишут компиляторы?
http://clang.llvm.org/
http://gcc.gnu.org/
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
18.04.2011, 11:51  [ТС]
И что это?
0
Заблокирован
18.04.2011, 11:53
Цитата Сообщение от taras atavin Посмотреть сообщение
И что это?
сходить по ссылке не осилил?
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
18.04.2011, 11:58  [ТС]
По обеим ссылкам я зашёл. Но о языке разработки хоть какого то компилятора упоминаний не увидел.
0
Заблокирован
18.04.2011, 12:01
Цитата Сообщение от taras atavin Посмотреть сообщение
По обеим ссылкам я зашёл. Но о языке разработки хоть какого то компилятора упоминаний не увидел.
...объясняю на пальцах для одаренных :

gcc _КОМПИЛЯТОР_ с _ОТКРЫТЫМ_ исходным текстом ... значит тебе только остается зайти в репозиторий сорцов либо скачать их и глянуть на чем написано , тоже самое и с clang , также зайти и глянуть на чем он написан
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
18.04.2011, 12:07  [ТС]
Цитата Сообщение от unStatiK Посмотреть сообщение
gcc _КОМПИЛЯТОР_ с _ОТКРЫТЫМ_ исходным текстом ... значит
Только вместо ожидаемого кода самого компила по ссылке предлагаются примеры фрагментов компилируемых программ.

Добавлено через 1 минуту
Причём, gcc у меня установлен, но как заглянуть в его исходник, я всё равно не понимаю.
0
Заблокирован
18.04.2011, 12:09
Цитата Сообщение от taras atavin Посмотреть сообщение
Только вместо ожидаемого кода самого компила по ссылке предлагаются примеры фрагментов компилируемых программ.

Причём, gcc у меня установлен, но как заглянуть в его исходник, я всё равно не понимаю.
http://gcc.gnu.org/svn.html
http://gcc.gnu.org/mirrors.html

а теперь проследуй в биореактор....
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
18.04.2011, 12:11  [ТС]
Здесь исходника самого компила тоже не видно.

Добавлено через 1 минуту
Цитата Сообщение от unStatiK Посмотреть сообщение
http://gcc.gnu.org/svn.html
http://gcc.gnu.org/mirrors.html

а теперь проследуй в биореактор....
Вот что там валяется:
GCC: Anonymous read-only SVN access

Our SVN source repository is available read-only to the public at large. That way you can pick up any version (including releases) of GCC that is in our repository.

Our web pages are still maintained via CVS, and can be accessed using the directions for our CVS setup.

In addition you can browse our SVN history online.
Using the SVN repository

Assuming you have version 1.0.0 and higher of Subversion installed, you can check out the GCC sources using the following command:

svn checkout svn://gcc.gnu.org/svn/gcc/trunk SomeLocalDir

If you are behind a firewall that does not allow the svn protocol through, you can replace svn:// with http://. You may also need to modify your subversion servers file (~/.subversion/servers) to set http-proxy-host and http-proxy-port. You should only use the http protocol if the svn protocol does not work; the http protocol has a higher server overhead associated with it and will be slower.

There is more information about Subversion specifically for GCC in the GCC Wiki.
Generated files

Our source tree contains a number of files that are generated from other source files by build tools such as Bison, Autoconf, and Gperf. Bison is now required when using SVN to access our sources, but all other generated files are included in the source tree so that GCC can be built without these build tools. The SVN checkout and update operations do not insure that the timestamps of generated files are later than those of the files they are generated from. The script contrib/gcc_update updates the timestamps for all these generated files. See the comments in that script for instructions on running it.

GCC's build system (in particular Make) uses file timestamps to determine if a generated file needs to be updated by running a particular build tool. Because of this, GCC's build system may believe that a generated file needs regenerating even though its source has not changed, and require a particular build tool to rebuild that generated file. If the appropriate build tool is installed on your system, then this will not be a problem. If you do not intend to make changes to the source, you can avoid installing these build tools by running contrib/gcc_update.

There has been some discussion of removing these generated files from GCC's SVN source tree (there is no discussion of removing them from the released source tarballs). If that happens then building GCC from the SVN source tree would require installing the above mentioned build tools. Installing these build tools is not particularly difficult, but can be time consuming especially if you only occasionally install GCC on a particular system.

The build tools that GCC uses are all available from the GNU Project (see http://www.gnu.org), are often already available on many systems, and can often be found already built for some systems. A partial list of these build tools is: Autoconf, Bison, Xgettext, Automake, and Gperf.
Conflicts when using svn update

It is not uncommon to get svn conflict messages for some generated files when updating your local sources from the SVN repository. Typically such conflicts occur with autoconf generated files.

As long as you haven't been making modifications to the generated files or the generator files, it is safe to delete the offending file, then run svn update again to get a new copy.
Branches and Tags

A branch called branchname can be checked out with the following command:

svn co svn://gcc.gnu.org/svn/gcc/branches/branchname gcc

(The release branch of the latest version of GCC x.y is named gcc-x_y-branch.)

Similarly a tag called tagname can be checked out with the following command:

svn co svn://gcc.gnu.org/svn/gcc/tags/tagname gcc

(For recent releases, the SVN tag for GCC X.Y.Z is of the form gcc_X_Y_Z_release.)

The following list provides some representative examples:

* gcc-4_3-branch
* gcc_4_3_4_release
* gcc_4_3_3_release
* gcc_4_3_2_release
* gcc_4_3_1_release
* gcc_4_3_0_release
* gcc-3_4-branch
* gcc_3_4_3_release
* gcc_3_4_2_release
* gcc_3_4_1_release
* gcc_3_4_0_release

To get a list of available branches, use the command:

svn ls svn://gcc.gnu.org/svn/gcc/branches

To find out the revision/date at which a branch or tag was created, use the command svn log --stop-on-copy.
Active Development Branches
General Infrastructure

struct-reorg-branch
This branch is for the development of structure reorganization optimizations, including field reordering, structure splitting for trees. These optimizations are profile information driven. This is a subbranch of tree-profiling. This branch is being maintained by Caroline Tice, Dale Johannesen, Kenneth Zadeck, Stuart Hastings, Mostafa Hagog.
autovect-branch
This branch is the successor to the lno-branch. The purpose of this branch is tree-level autovectorization work, and related work that the autovectorizer could use or benefit from (like data-dependence analysis, loop nest optimizations).
graphite-branch
The purpose of this branch is to develop an infrastructure for loop transforms using the polyhedral model.
lw-ipo
This branch aims to implement lightweight IPO. Patches and discussion on this branch should be marked with the tag [lipo] in the subject line. The branch is maintained by David Li.
gimple-front-end
This branch implements a front end for GIMPLE. It is maintained by Diego Novillo. Patches should be prefixed with [gimplefe] in the subject line. See the GIMPLE Front End page for details.
ra-improvements
This branch aims to implement several improvements to the current register allocator. Examples include implementing a lower-triangular conflict matrix and register coalescing. It is hoped that these improvements will not only help the current allocator, but will be useful to the other register allocation projects such as RABLE and YARA. This branch will be merged with the dataflow-branch from time to time. The patches for this branch should be marked with the tag [ra-improvements] in the subject line. The branch is maintained by Peter Bergner.
ira
This branch contains the Integrated Register Allocator (IRA). It is based on work done on yara-branch. The latter is more of a research branch because one of its goals (removing reload) is too remote. The ira branch is focused to prepare some code for GCC mainline, hopefully in time for GCC 4.4. IRA still uses reload; it is called integrated because register coalescing and register live range splitting are done on-the-fly during coloring. The branch is maintained by Vladimir Makarov < vmakarov@redhat.com> and will be merged with mainline from time to time. Patches will be marked with the tag [ira] in the subject line.
ira-merge
This branch contains bug fixes for the Integrated Register Allocator (IRA). It is branched from trunk at revision 139590 when IRA was merged into trunk. It is used to track IRA related regressions. Only IRA fixes from trunk will be applied to this branch. Its goal is there should be no "make check" and performance regressions against trunk at revision 139589. The branch is maintained by H.J. Lu <hjl.tools@gmail.com> and Vladimir Makarov < vmakarov@redhat.com>.
sel-sched-branch
This branch contains the implementation of the selective scheduling approach. The goal of the branch is to provide more aggressive scheduler implementation with support for instruction cloning, register renaming, and forward substitution. The branch is maintained by Andrey Belevantsev <abel@ispras.ru> and Maxim Kuvyrkov < mkuvyrkov@ispras.ru> and will be regularly merged with mainline. Patches will be marked with the tag [sel-sched] in the subject line.
incremental-compiler
This branch contains change to turn GCC into an incremental compiler. The branch is maintained by Tom Tromey tromey@redhat.com. Patches for this branch should be marked with the tag [incremental] in the subject line.
gc-improv
This branch is for the development of garbage collector improvements. It is the successor to the boehm-gc branch, but without integration with Boehm's GC. The branch is maintained by Laurynas Biveinis. Patches for this branch should be marked with the tag [gc-improv] in the subject line.
milepost-branch
This branch is for GCC developments done in the Milepost project. (http://www.milepost.eu). The branch is maintained by Mircea Namolaru namolaru@il.ibm.com. Patches should be marked with the tag [mpost] in the subject line.
melt-branch
This branch is for a Middle End Lisp Translator branch, including both the plugin Lisp-like facility and static analyzers developed with it. This branch is maintained by Basile Starynkevitch basile@starynkevitch.net. Use the [MELT] tag for patches.
stack
This branch contains a new stack alignment framework to automatically align stack for local variables with alignment requirement. The branch is maintained by H.J. Lu <hjl.tools@gmail.com>, Joey Ye <joey.ye@intel.com> and Xuepeng Guo <xuepeng.guo@intel.com>. Patches should be marked with the tag [stack] in the subject line.
thread-annotations
This branch contains the implementation of thread safety annotations and analysis (http://gcc.gnu.org/wiki/ThreadSafetyAnnotation). The branch is maintained by Le-Chun Wu. Patches and discussion on this branch should be marked with the tag [thread-annotations] in the subject line.
rtl-fud-branch
This branch is for the development of factored use-def chains as an SSA form for RTL. Patches should be marked with the tag [rtl-fud] in the subject line. The branch is maintained by Steven Bosscher and Kenneth Zadeck.
transactional-memory
This branch is for the development of transactional memory support for GCC. Patches for this branch should be marked [trans-mem] in the subject line. The branch is maintained by Richard Henderson.
cxx-mem-model
This branch is for the implementation of the C++ memory model. Patches for this branch should be marked [cxx-mem-model] in the subject line. The branch is maintained by Aldy Hernandez.
dwarf4
This branch is for support of DWARF-4 features. DWARF-4 is currently under development, so changes on this branch will remain experimental until Version 4 is officially finalized.
plugins
This branch adds plugin functionality to GCC. See the plugins wiki page for details.
no-undefined-overflow
This branch is for tracking overflow behavior on expressions rather than on types. Patches should be marked with the tag [no-undefined-overflow] in the subject line. The branch is maintained by Richard Guenther.
debuglocus
This branch is an experiment to see whether improved debug information can be maintained throughout the compiler by associating a user decl with an expression, statement, or insn. The name comes from attempting to utilize the ever present source location (locus) field to carry the debug info. Further information can be found on the debuglocus wiki page .
alias-export
This branch contains the alias export and data dependency export patch. It is used to experiment with the propagation process. This branch is maintained by Andrey Belevantsev abel@ispras.ru.
vect256
This branch is for extending vectorizer to 256bit. The branch is maintained by Richard Guenther and H.J. Lu. Patches should be marked with the tag [vect256] in the subject line.

Architecture-specific

st/cli-be
The goal of the branch is to develop a back-end producing CLI binaries, compliant with ECMA-335 specification. This branch was originally maintained by Roberto Costa <robsettantasei@gmail.com>. Since May 2007, the current maintainers are Andrea Ornstein <andrea.ornstein@st.com> and Erven Rohou <erven.rohou@st.com>.
ix86/avx
The goal of this branch is to implement Intel AVX (Intel Advanced Vector Extensions). The branch is maintained by H.J. Lu <hjl.tools@gmail.com>, Joey Ye <joey.ye@intel.com> and Xuepeng Guo <xuepeng.guo@intel.com>. Patches should be marked with the tag [AVX] in the subject line.
ix86/gcc-4_5-branch
The goal of this branch is to backport support from trunk for newer ix86 processors from AMD and Intel. It will track 4.5 branch with periodic merge from 4.5 branch. The current maintainers are Sebastian Pop <sebpop@gmail.com> and H.J. Lu <hjl.tools@gmail.com>.
ix86/gcc-4_4-branch
The goal of this branch is to add support for newer ix86 processors such as AMD's Shanghai and Intel's Atom to GCC 4.4.x. The current maintainers are Dwarakanath Rajagopal <dwarak.rajagopal@amd.com> and H.J. Lu <hjl.tools@gmail.com>.
ix86/gcc-4_3-branch
The goal of this branch is to add support for newer ix86 processors such as AMD's Barcelona and Intel's Westmere to GCC 4.3.x. The current maintainers are Dwarakanath Rajagopal <dwarak.rajagopal@amd.com> and H.J. Lu <hjl.tools@gmail.com>.
ix86/gcc-4_2-branch
The goal of this branch is to add support for newer ix86 processors such as AMD's Barcelona and Intel's Core 2 to GCC 4.2.x. The current maintainers are Dwarakanath Rajagopal <dwarak.rajagopal@amd.com> and H.J. Lu <hjl.tools@gmail.com>.
ix86/gcc-4_1-branch
The goal of this branch is to add support for newer ix86 processors such as AMD's Barcelona and Intel's Core 2 to GCC 4.1.x. The current maintainers are Dwarakanath Rajagopal <dwarak.rajagopal@amd.com> and H.J. Lu <hjl.tools@gmail.com>.
ARM/hard_vfp_4_4_branch
This branch contains support for the hard-VFP variant of the AAPCS calling standard and tracks the gcc-4.4 development. This branch is maintained by Richard Earnshaw.
cell-4_3-branch
The goal of this branch is to add fixes and additional features required for the Cell/B.E. processor (both PPE and SPE) to GCC 4.3.x. This branch is maintained by Ulrich Weigand.
cell-4_4-branch
The goal of this branch is to back-port from mainline fixes and additional features required for the Cell/B.E. SPE processor to GCC 4.4.x. This branch is maintained by Ulrich Weigand. The branch is merged from gcc-4_4-branch.
spu-4_5-branch
The goal of this branch is to do development for the Cell/B.E. processor, in particular to support partitioning functions into multiple sections. This branch was created by Michael Meissner and is now maintained by Ulrich Weigand. The branch is merged from mainline.
arc-20081210-branch
The goal of this branch is to make the port to the ARCompact architecture available. This branch is maintained by Joern Rennecke during spring 2009, and is expected to be unmaintained thereafter.
microblaze
This branch contains support for the Xilinx MicroBlaze architecture. This branch will be used to update MicroBlaze support from gcc-4.1.2 to to the head. It is maintained by Michael Eager <eager@eagercon.com>.
x32
This branch is to implement x32 psABI. The branch is maintained by H.J. Lu. Patches should be marked with the tag [x32] in the subject line.

Target-specific

cygwin-improvements
This branch is intended as a development and proving grounds for fixes and enhancements specifically to the Cygwin port of the compiler, although some of these may touch slightly on MinGW targets as well. It is maintained by Dave Korn <dave.korn.cygwin@gmail.com> and open to contributions from any interested party; please tag patches with "[cygwin-improvements]" in the title line and post them to the GCC Patches list with a Cc: to that address.

Language-specific

fortran-dev
This branch is for disruptive changes to the Fortran front end, especially for OOP development and the array descriptor update. It is maintained by Jerry DeLisle <jvdelisle@gcc.gnu.org>.
fortran-exp
This branch is for experimental changes to the Fortran front end, initially for array constructor refactoring using splay-tree and other areas of optimization. It is maintained by Jerry DeLisle <jvdelisle@gcc.gnu.org>.
gccgo
This branch is for the Go frontend to gcc. For more information about the Go programming language, see http://golang.org. The branch is maintained by Ian Lance Taylor. Patches should be marked with the tag [gccgo] in the Subject line.
gupc
This branch implements support for UPC (Unified Parallel C). UPC extends the C programming language to provide support for high-performance, parallel systems with access to a single potentially large, global shared address space. Further information can be found on the GNU UPC web page.
gcc-4_4-plugins
This branch is for backporting the plugin functionality into a 4.4-based release. There will be no new code or functionality added to this branch. It is maintained by Diego Novillo. Only patches backported from mainline are accepted. They should be marked with the tag [4_4-plugins] in the Subject line.
pph
This branch implements Pre-Parsed Headers for C++. It is maintained by Diego Novillo and Lawrence Crowl. Patches should be prefixed with [pph] in the subject line.

Distribution Branches

These branches are maintained by organizations distributing GCC. No changes should be made to those branches without the explicit permission of the distributing organization. The branch name should be prefixed with the initials of the distributing organization.

apple-local-200502-branch
This branch is for various improvements in use at Apple and to coordinate work with others. This branch is maintained by the folks at Apple. Previous branch was apple-ppc-branch.
csl-3_3_1-branch
CodeSourcery release based on GCC 3.3.1.
csl-arm-2004-q3-branch
CodeSourcery ARM 2004-Q3 release
csl-3_4-linux-branch
CodeSourcery GNU/Linux compilers based on GCC 3.4.x.
csl-3_4_3-linux-branch
CodeSourcery GNU/Linux compilers based on GCC 3.4.3, with patches from the csl-arm-branch.
csl-gxxpro-3_4-branch
CodeSourcery's Sourcery G++ compilers, based on GCC 3.4.x.
csl-sol210-3_4-branch
CodeSourcery branch for developing Solaris 2.10 AMD64 support for GCC 3.4; this branch is used for the system compilers in OpenSolaris. This branch is maintained by CodeSourcery personnel. Patches should be marked with the tag [csl-sol210-branch] in the subject line.
google/integration
This branch contains some minimal patches that are likely not useful anywhere outside of Google's build environment. These are typically configuration patches. The branch is maintained by Diego Novillo dnovillo@google.com.
google/main
This branch contains Google local patches that are staged to be contributed to trunk. Some of these patches are either in the process of being reviewed, or have not yet been proposed. The intent of this branch is to serve as a staging platform to allow collaboration with external developers. Patches in this branch are only expected to remain here until they are reviewed and accepted in trunk. This branch is maintained by Diego Novillo dnovillo@google.com.
ibm/gcc-4_1-branch
This branch provides decimal float support backported to GCC 4.1.x. It is expected to be used primarily within IBM for PowerPC-64 GNU/Linux. The branch is maintained by Janis Johnson <janis@us.ibm.com>.
ibm/gcc-4_3-branch
This branch is expected to be used primarily within IBM for PowerPC-64 GNU/Linux.
ibm/gcc-4_4-branch
This branch is expected to be used primarily within IBM for PowerPC-64 GNU/Linux.
ibm/power7-meissner
This branch is a private development branch for Power7 (PowerPC ISA 2.06) development, prior to the patches being submitted to the mainline. The branch is maintained by Michael Meissner, meissner@linux.vnet.ibm.com.
redhat/gcc-3_2-branch
Red Hat GNU/Linux compilers based on GCC 3.2.x.
redhat/gcc-3_4-branch
Red Hat GNU/Linux compilers based on GCC 3.4.x.
redhat/gcc-4_0-branch
Red Hat GNU/Linux compilers based on GCC 4.0.x.
redhat/gcc-4_1-branch
Red Hat GNU/Linux compilers based on GCC 4.1.x.
redhat/gcc-4_3-branch
Red Hat GNU/Linux compilers based on GCC 4.3.x.
suse/gcc-4_1-branch
SUSE GNU/Linux compilers based on GCC 4.1.x.
suse/gcc-4_2-branch
SUSE GNU/Linux compilers based on GCC 4.2.x.
ubuntu/gcc-4_2-branch
This branch follows the gcc-4_2-branch, except for gcc/java, boehm-gc, libffi, libjava and zlib, which are backported from the trunk (and from gcc-4_3-branch, once created). The branch is used as the base for the Debian and Ubuntu gcc-4.2 source package.

Inactive Development Branches

dfp-branch
edge-vector-branch
cp-parser-branch
cp-parser-branch-2
pch-branch
gcc-3_4-basic-improvements-branch
mips-3_4-rewrite-branch
dfa-branch
gcj-abi-2-dev-branch
gcj-eclipse-branch
tree-ssa-20020619-branch
csl-sol210-branch (Solaris 2.10 AMD64 support)
gomp-20050608-branch
gomp-3_0-branch
fixed-point
gimple-tuples-branch
c-4_5-branch
alias-improvements
cond-optab
var-tracking-assignments*-branch
mem-ref2
These branches have been merged into the mainline.
apple-ppc-branch
This branch was for various improvements in use at Apple and to coordinate work with others. This branch was maintained by the folks at Apple. It has been superseded by apple-local-200502-branch.
stree-branch
This branch was for improving compilation speed and reducing memory use by representing declarations as small flat data structures whenever possible, lazily expanding them into full trees when necessary. This branch was being maintained by Matt Austern, Robert Bowdidge, Geoff Keating, and Mike Stump. Patches were marked with the tag [stree] in the subject line.
compile-server-branch
This branch was aimed at improving compile speed by caching work done between compilations. The work saved is mainly related to header file processing. This branch was maintained by Mike Stump and Per Bothner. Patches were marked with the tag [cs] in the subject line.
libobjc-branch
The branch is aimed to clean up libobjc and make it run on Darwin. Patches should be marked with the tag [libobjc-branch] in the subject line. Patches can be approved by Andrew Pinski <pinskia@gcc.gnu.org> or Nicola Pero <n.pero@mi.flashnet.it>.
cfg-branch
This branch was created to develop and test infrastructure for easier writing of new RTL based optimizations. The branch was based on GCC pre-3.3 and has been partially merged into the mainline for GCC 3.4. It is now closed, and work continues on the rtlopt-branch.
pointer_plus
This branch is for the development of POINTER_PLUS_EXPR. Which is to be used instead of casting between an integer type and a pointer type before doing pointer addition. This branch is being maintained by Andrew Pinski. Patches for this branch should be marked with the tag [PTR-PLUS] in the subject line, and CC'ed to Andrew Pinski.
tree-ssa-cfg-branch
This branch has been merged into the tree-ssa-20020619-branch.
ast-optimizer-branch
The purpose of this branch was to improve GCC's tree based optimizations. The patches of this branch have been moved to the tree-ssa-20020619-branch.
faster-compiler-branch
This was a temporary branch for compiler speedups for GCC 3.4. See this thread for discussion of possible work still to be done in this area. The branch is unmaintained at present.
gcc-3_3-e500-branch
This branch was for backporting the PowerPC/E500 back end to GCC 3.3. See this message for details.
gcc-3_4-e500-branch
This branch was for stabilization of the powerpc-*spe architecture, and for adding support for the 8548 chip (e500 v2). This branch was maintained by Aldy Hernandez. All the e500 support was merged to mainline.
gomp-01-branch
gomp-branch
These two branches were initial attempts to implement OpenMP support in GCC. They were never properly maintained and have now been superseded by gomp-20050608-branch.
lno-branch
A sub-branch of tree-ssa that aims at implementing a loop nest optimizer at the tree level. Was largely merged into mainline, and is currently unmaintained. This work now continues on the autovect-branch.
java-gui-branch
This was a temporary branch for development of java GUI libraries (AWT and Swing) in the libjava directory. It has been superseded by java-gui-20050128-branch
java-gui-20050128-branch
This was a temporary branch for development of java GUI libraries (AWT and Swing) in the libjava directory. It has been merged into mainline.
gcjx-branch
This branch was used for development of gcjx, a rewrite of the front end for the Java programming language. It has been superseded by gcj-eclipse-branch.
csl-hpux-branch
This branch was for changes to G++ to be more compatible with ABI bugs in the HP-UX C++ compiler. It is now unmaintained.
tree-cleanup-branch
This branch contained improvements and reorganization to the tree optimizers that were not ready in time for GCC 4.0. The goal was to cleanup the tree optimizers and improve the sequencing of the passes. It has now been merged into mainline for the 4.1 release.
bje-unsw-branch
This branch was dedicated to some research work by Ben Elliston at the University of New South Wales (UNSW) on transformation phase ordering. It will never merge with mainline, although a selection of patches may be submitted over time. Deleted by revision 152653.
redhat/gcc-3_3-branch
This branch used to hold Red Hat GNU/Linux compilers based on GCC 3.3.x.
rtlopt-branch
This branch was the successor to the cfg-branch, with the exception that it was based on GCC pre-3.4. The purpose of the branch was to develop and test infrastructure for CFG based code improving transformations on RTL.
killloop-branch
The missing optimizations and optimization improvements necessary for removing the old loop optimizer were developed on this branch. Most of these changes were merged in 4.2.
ssaupdate-branch
This branch served to clean up and improve utilities for the SSA form updating, as well as for related changes of the SSA form representation. Most of the changes in this branch were never merged. Part of them were incorporated in Diego Novillo's SSA updating improvement patch.
predcom
This branch aimed to implement predictive commoning optimization and to introduce the changes to the representation of Fortran arrays, alias analysis and dependency analysis to make it useful for the common applications (e.g., mgrid). The branch was merged in 4.3.
dataflow-branch
This branch has been merged into mainline on June 6, 2007 as svn revision 125624. It used to contain replacement of backend dataflow with df.c based dataflow. The branch was maintained by Daniel Berlin < dberlin@dberlin.org> and Kenneth Zadeck < zadeck@naturalbridge.com>
cxx0x-branch
This branch was for the development of C++0x features, and all features developed on this branch have been merged to mainline. Future C++0x features will be developed against mainline. This branch was deleted at revision 152320.
cxx0x-concepts-branch
This branch contains the beginnings of a re-implementation of Concepts, a likely future feature of C++, using some of the code from the prototype implementation on conceptgcc-branch. It is not currently maintained.
cxx0x-lambdas-branch
This branch was for the development of lambda functions, a coming feature in C++0x. It was merged into the trunk at revision 152318.
tree-profiling-branch
This branch was for the development of profiling heuristics and profile based optimizations for trees, such as profile driven inline heuristics. Another goal of this branch was to demonstrate that maintaining the CFG and profile information over expanding from GIMPLE trees to RTL is feasible and can bring considerable performance improvements. It is no longer maintained.
new-regalloc-branch
Daniel Berlin and Michael Matz were working on an implementation of a graph-coloring register allocator on this branch. It is known to bootstrap under x86-linux-gnu and ppc-linux-gnu. It is no longer maintained.
structure-aliasing-branch
This branch contains improvements to the tree optimizers ability to do pointer-to-structure aliasing analysis and optimization. This involves some significant rework of the way our memory information is represented in the tree-ssa form. The branch was maintained by Daniel Berlin. It is no longer maintained.
cfo-branch
The goal of this branch was to add a new extension for improving the code size optimization of GCC with code factoring methods (code motion and merging algorithms). It is no longer maintained.
reload-branch
This branch contains a version of reload in which the tracking of reload register lifetimes and the inheritance code has been rewritten in an attempt to make it more maintainable. It is no longer maintained.
dead/improved-aliasing-branch
This branch contains improvements to the tree-based aliasing infrastructure. The branch was maintained by Daniel Berlin <dberlin@dberlin.org> and Diego Novillo < dnovillo@redhat.com>. It is no longer maintained.
sched-treegion-branch
This branch was for the development of a treegion-based instruction scheduler. The branch was maintained by Chad Rosier. It is no longer maintained.
mem-ssa
This branch contains the implementation of Memory SSA, a new mechanism for representing memory operations in SSA form (http://gcc.gnu.org/ml/gcc/2006-02/msg00620.html). The branch was maintained by Diego Novillo. It is no longer maintained.
yara-branch
This branch contains Yet Another Register Allocator (YARA). The branch was maintained by Vladimir Makarov < vmakarov@redhat.com>. It is no longer maintained; some of the work was used as a basis for the work on the ira branch.
opt-diary
This branch contains the implementation of Optimization Diary, a collection of useful log information generated by the optimizers. This branch was maintained by Devang Patel. It is no longer maintained.
insn-select
This branch aimed to implement in early instruction selection and register class selection pass, which runs before register allocation and subsumes the current regclass pass. In particular the goal is to chose an alternative per instruction, usable as a base during register allocation, which ideally is not changed during reload if registers could be allocated. This will not be possible in all cases, especially when addresses generated during spilling will be invalid on the target machine. But we should be able to do away with fake register classes representing strict unions of other register classes. The branch was maintained by Michael Matz. It is no longer maintained.
addressing-modes
This branch aimed to clean up the way base and index registers are handled by target headers. In particular, the strict and non-strict meaning of these registers are unified and a common API is presented to implementations of the target macros. Obsolete target macros will also be removed. The branch was maintained by Paolo Bonzini. It is no longer maintained.
csl-arm-branch
CodeSourcery branch for developing ARM back end improvements. The branch was maintained by CodeSourcery personnel. It is no longer maintained; almost all the patches have been merged to mainline.
csl/coldfire-4_1
CodeSourcery branch for developing ColdFire back end improvements. The branch was maintained by CodeSourcery personnel. It is no longer maintained; almost all the patches have been merged to mainline.
ia64-fp-model-branch
This branch was a development branch with the goal of implementing the improvements and features discussed at the ia64 floating point page on the GCC wiki. It was maintained by Zack Weinberg <zack@codesourcery.com>. It is no longer maintained.
ia64-improvements
The goal of this branch was to improve the performance of binaries generated with GCC on the Itanium processor. Details of current projects on this branch can be found at the Gelato GCC wiki and at the IA-64 improvements page. This branch was maintained by Robert Kidd <rkidd@crhc.uiuc.edu> and Diego Novillo. It is no longer maintained.
cxx-reflection-branch
Part of the work on providing support for compile time reflection in C++ was done in this branch. This branch was maintained by Gabriel Dos Reis <gdr@integrable-solutions.net>. It is no longer maintained.
hammer-3_3-branch
The goal of this branch was to have a stable compiler based on GCC 3.3 with improved performance for AMD's 64-bit Hammer CPUs. The branch was maintained by Jan Hubicka <jh@suse.cz> and Andreas Jaeger <aj@suse.de>. Patches added on this branch might not be appropriate for the GCC 3.3 branch due to our policies concerning release branches. All patches were added to mainline GCC (for 3.4).
objc-improvements-branch
This branch was originally used to merge Objective-C bug fixes and enhancements from Apple Computer into the FSF tree; this has now been completed. A later purpose of the branch was to implement the Objective-C++ language in the FSF GCC source tree. The message thread starting here describes this at more length. This branch was being maintained by Zem Laski <zlaski@apple.com>. It is no longer maintained.
libada-gnattools-branch
This is the spiritual successor to the libada branch. This branch exists to solve bug 5911 and others, by breaking out the Ada runtime into a libada directory and the Ada tools into a gnattools directory. Work was devoted to cleaning up the configure and make machinery, and separating it as much as possible from the GCC build machinery. Nathanael Nerode <neroden@gcc.gnu.org> maintained this branch. It is no longer maintained.
libstdcxx_so_7-branch
This was a branch for experimental work on the C++ Runtime Library (libstdc++-v3) beyond the current version 6 library ABI. Paolo Carlini <pcarlini@suse.de> and Benjamin Kosnik <bkoz@redhat.com> were maintaining this branch. It is no longer maintained.
function-specific-branch
This branch is for development of adding function specific options to GCC. See the GCC wiki for a more detailed project description. Patches should be marked with the tag [function-specific] in the subject line. The branch has been merged into GCC 4.4.
lto-streamer
This was a sub-branch of the lto branch. It was intended for unstable work related to the conversion from DWARF encoding to GIMPLE streamer. It is no longer maintained.
plugin
This branch contains work for a plugin infrastructure in GCC to enable additional checking work. This branch is maintained by Eric Christopher echristo@gmail.com and will be merged with mainline from time to time. Patches will be marked with the tag [plugin] in the subject line.
condate-branch
The purpose of this branch is to develop a language for checking control flow graph properties. The code of this branch has not been merged in trunk.
miro-branch
The purpose of this branch is to develop an improved Mudflap with referent objects. The code of this branch has not been merged in trunk.
var-mappings-branch
This branch is for improving debug information based on tracking multiple variables per computed value. The branch is maintained by Richard Guenther and Michael Matz. Patches should be marked with the tag [varmap] in the subject line.
mem-ref
This branch is for lowering the GIMPLE IL for memory accesses to a flat representation. See the GCC wiki for a more detailed project description. The branch is maintained by Richard Guenther. Patches should be marked with the tag [mem-ref] in the subject line.
gcc-in-cxx
This branch was for converting GCC to be written in C++. The branch was maintained by Ian Lance Taylor.
ibm/power7-tmp
This branch was used to stage patches for Power7 (PowerPC ISA 2.06) from the development branch to the mainline. The branch was maintained by Michael Meissner, meissner@linux.vnet.ibm.com.
lto
This branch implemented link-time optimization.
named-addr-spaces-branch
This branch was the development branch to add named address space support for architectures that have multiple address spaces. The CELL/spu architecture adds an __ea keyword to describe extended memory in the host chip address space instead of the local CELL/spu address space. The branch was created by Ben Elliston, modified by Michael Meissner and eventually maintained by Ulrich Weigand. All changes from this branch were merged into mainline.
named-addr-4_3-branch
The goal of this branch was to backport the changes from the named-addr-spaces-branch to a GCC 4.3 tree. This branch was maintained by Michael Meissner. This branch was merged from gcc-4_3-branch.
split
For development of stack splitting, as described on the GCC wiki. This branch was maintained by Ian Lance Taylor. All changes were merged into mainline.
boehms-gc
The goal of this branch was to test Boehm's GC feasibility as the garbage collector for GCC proper. This was a part of Google Summer of Code project, described in detail at http://gcc.gnu.org/wiki/Garbage_collection_tuning. The branch was maintained by Laurynas Biveinis.

For questions related to the use of GCC, please consult these web pages and the GCC manuals. If that fails, the gcc-help@gcc.gnu.org mailing list might help. Comments on these web pages and the development of GCC are welcome on our developer list at gcc@gcc.gnu.org. All of our lists have public archives.

Copyright (C) Free Software Foundation, Inc. Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.

These pages are maintained by the GCC team. Last modified 2011-04-15.
. А где исходник то?
0
Заблокирован
18.04.2011, 12:14
Цитата Сообщение от taras atavin Посмотреть сообщение
Вот что там валяется: . А где исходник то?
http://www.gnuman.ru/stuff/svn/

тебе без очереди сказали пройти ....
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
18.04.2011, 12:26  [ТС]
Цитата Сообщение от unStatiK Посмотреть сообщение
Издеваешься?

Добавлено через 2 минуты
Цитата Сообщение от $$$$ Посмотреть сообщение
Это parser generator, черным по белому написано.
И где это написано?

Добавлено через 3 минуты
Вот, что я нашёл по парсер генератору. Как его скачать всё равно не понятно, по даунлоаду он не находит файлов архива.

Добавлено через 1 минуту
И ещё. Эйси, предположим, парсер сгенерится. А компилятор?
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
18.04.2011, 12:35  [ТС]
А где она валяется?
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
18.04.2011, 13:04  [ТС]
Цитата Сообщение от $$$$ Посмотреть сообщение
Но не расстраивайся: в ВУЗ поступишь
Я его в 2000-м закончил. А в 2007-м защитил диссертацию.

Добавлено через 36 секунд
Цитата Сообщение от $$$$ Посмотреть сообщение
ройти по ссылке
А по-русски нельзя?
0
 Аватар для 0xAX
2451 / 362 / 9
Регистрация: 27.06.2009
Сообщений: 880
18.04.2011, 19:45
Цитата Сообщение от taras atavin Посмотреть сообщение
На чём пишут компиляторы?
На языках программирования, внезапно Вас какой - то конкретный компилятор интересует? Или вообще?
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
19.04.2011, 05:27  [ТС]
Цитата Сообщение от $$$$ Посмотреть сообщение
Неужели в раше степени теперь раздают каждому дворнику?
Про дворников тебе лучше знать.

Добавлено через 5 минут
Цитата Сообщение от only# Посмотреть сообщение
На языках программирования,
Ну это понятно. Но и плюсы, и ассемблер - языки программирования.

Добавлено через 2 минуты
Цитата Сообщение от $$$$ Посмотреть сообщение
Либо ОЧЕНЬ толсто, либо I fold
Ты где видел, чтоб преподавание технической дисциплины велось целиком на иностранном языке? В Израиле? Я еврей, но не до такой же степени, чтоб всё по-нерусски.
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
19.04.2011, 05:31  [ТС]
Пойдёт?
Миниатюры
На чём пишут компиляторы?  
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
19.04.2011, 07:02  [ТС]
И это?

Добавлено через 1 минуту
Имеет ли смысл при анализе строить таблицу типов?

Добавлено через 14 минут
На хорошем языке высокого уровня программы пишутся быстро и писать их удобно и относительно просто. Но если реализован хороший язык, то зачем писать ещё один компилятор? А если не реализован, но остаётся фигня, на которой, писать сложно и не удобно, а сам процесс занимает много времени. Причём, косые языки всокого уровня ещё и ограничены в своих возомжносях. На языке ассемблера можно писать всё, он подлинно универсален, но он ещё сложнее, медленее и неудобнее. Ну вот я и хочу спросить: если бы вы взялись за написание компиляторов, то какие языки вы бы выбрали для этой цели? Какие языки по-вашему лучше для такой задачи?

Добавлено через 15 минут
ХЕШ-АДРЕСАЦИЯ

Идеальный вариант - уметь по имени сразу определить адрес элемента. В этом смысле "хорошей" процедурой поиска является та, которая сможет определить хотя бы приблизительный адрес элемента. Одним из наиболее эффективных и распространенных методов реализации такой процедуры является хеш-адресация.

Хеш-адресация - это метод преобразования имени в индекс элемента в таблице. Если таблица состоит из N элементов, то им присваиваются номера 0,1,..,N-1. Тогда назовем хеш-функцией некоторое преобразование имени в адрес. Простейший вариант хеш-функции - это использование внутреннего представления первой литеры имени.

Пока для двух различных символов результаты хеширования различны, время поиска совпадает с временем, затраченным на хеширование. Однако, все проблемы начинаются тогда, когда результаты хеширования совпадают для двух и более различных имен. Эта ситуация называется коллизией.

Хорошая хеш-функция распределяет адреса равномерно, так что коллизии возникают не слишком часто. Но прежде, чем говорить о реализации хеш-функций, обратимся к вопросу о том, каким образом разрешаются коллизии.
Не очень понял, как по имени можно вычислить адрес. Заранее чтоли раскидать все имена по соответсвующим адресам? Но тогда придётся ограничиться небольшим числом очень простых имён.

Добавлено через 23 минуты
ОК-ГРАММАТИКИ

Несмотря на кажущуюся общность КСГ, при описании естественно-подобных языков существуют ограничения, связанные с различного рода бесконтекстными согласованиями (рода, падежа, числа и т.п.).

Для решения проблемы подобных согласований можно ввести еще одну разновидность грамматик - грамматики определенных клауз. Их особенностью является наличие контекстуальных аргументов.

Рассмотрим, каким образом может осуществляться согласование родов. Допустим, у нас есть группа существительных (ГС), состоящая из местоимения (Мест), прилагательного (Прил) и существительного (Сущ). Тогда определение ГС, учитывающее согласование родов, может выглядеть так:

Гс R Мест(k), Прил(k), Сущ(k), ГС

При этом k является контекстуальным аргументом, отвечающим за согласование родов. Этот аргумент является логической переменной:

Мест(муж) R этот

Мест(жен) R эта

Прил(муж) R второй

Прил(жен) R вторая

Сущ(жен) R строка

Сущ(муж) R пароль

и т.д.
Зачем это нужно? Зачем вообще падежи в искуственном языке? Не проще ли специально сконструировать его безпадежным?
0
 Аватар для taras atavin
4226 / 1796 / 211
Регистрация: 24.11.2009
Сообщений: 27,562
19.04.2011, 13:25  [ТС]
В Израиле все технические дисциплины и точные науки преподают на английском.
0
 Аватар для resource2008
111 / 112 / 18
Регистрация: 11.03.2011
Сообщений: 421
03.05.2011, 01:03
по вопросу топика:
раньше делали на YACC.
сейчас не вдавался в подробности. не так интересно.

вообще по вопросу парсеров и лексеров http://vimeo.com/groups/29150/videos
тут можно посмотреть, правда всё на английском, как пример. мне очень понравилось как он объясняет.

по поводу языков программирования на которых пишется - оно в результате все равно приводится к самому низкому уровню.
т.е. в результате все команды разбиваются на дерево элементарных инструкций, которые реализуются на низкоуровневом языке.
0
Эксперт С++
1069 / 848 / 60
Регистрация: 30.04.2011
Сообщений: 1,659
03.05.2011, 01:24
Цитата Сообщение от taras atavin Посмотреть сообщение
На чём пишут компиляторы?
В основном на С++.
Но вообще-то - на всем.
И на паскале, и на ассемблере, и на С...
Используют компиляторы-компиляторов. Раньше LEX+YACC
Бесплатные flex+bizon/
Сейчас Coco/R. B еще много чего. antlr, например.
0
Надоела реклама? Зарегистрируйтесь и она исчезнет полностью.
inter-admin
Эксперт
29715 / 6470 / 2152
Регистрация: 06.03.2009
Сообщений: 28,500
Блог
03.05.2011, 01:24
Помогаю со студенческими работами здесь

На чем пишут приложения
Вот и суть, на чем пишкт приложения дл айос? и если я хочу написать, то смогу протестить на свое айпаде?

Что на чем пишут?
Недавно столкнулся с такой проблемой:Что на чем пишут? Visual studio - игры , Java - приложения для андройд , и т.д. До сих пор не могу...

На чем пишут Инсталер к програмам??
стало интиресно как работают инсталятори, помогмите розобратся... 1. на каком ПО их пишут? 2. какие требования к ОС 3. как программы...

На чем пишут оконные приложения
Привет. Столкнулся с вопросом. На чем пишут оконные профессиональные приложения в Visual Studio 2008 с++? Я свое приложение писал на...

На чем обычно пишут интерфейс?
Господа программисты, расскажите, на основе каких библиотек, фреймворков и т.д. вы обычно пишете интерфейс своих программ? Под Windows? Под...


Искать еще темы с ответами

Или воспользуйтесь поиском по форуму:
20
Ответ Создать тему
Новые блоги и статьи
PhpStorm 2025.3: WSL Terminal всегда стартует в ~
and_y87 14.12.2025
PhpStorm 2025. 3: WSL Terminal всегда стартует в ~ (home), игнорируя директорию проекта Симптом: После обновления до PhpStorm 2025. 3 встроенный терминал WSL открывается в домашней директории. . .
Access
VikBal 11.12.2025
Помогите пожалуйста !! Как объединить 2 одинаковые БД Access с разными данными.
Новый ноутбук
volvo 07.12.2025
Всем привет. По скидке в "черную пятницу" взял себе новый ноутбук Lenovo ThinkBook 16 G7 на Амазоне: Ryzen 5 7533HS 64 Gb DDR5 1Tb NVMe 16" Full HD Display Win11 Pro
Музыка, написанная Искусственным Интеллектом
volvo 04.12.2025
Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .
От async/await к виртуальным потокам в Python
IndentationError 23.11.2025
Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .
Поиск "дружественных имён" СОМ портов
Argus19 22.11.2025
Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .
Сколько Государство потратило денег на меня, обеспечивая инсулином.
Programma_Boinc 20.11.2025
Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .
Ломающие изменения в C#.NStar Alpha
Etyuhibosecyu 20.11.2025
Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .
Мысли в слух
kumehtar 18.11.2025
Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .
Создание Single Page Application на фреймах
krapotkin 16.11.2025
Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .
КиберФорум - форум программистов, компьютерный форум, программирование
Powered by vBulletin
Copyright ©2000 - 2025, CyberForum.ru