new compiler in openBSD
Based on the message osnews.com/story.php/18771/More-on-OpenBSDs-New-Compiler
A few weeks ago, the OpenBSD project announced that the Portable C Compiler was added to the OpenBSD source tree. And developers will try to make it a full replacement for GCC. Why?
According to Mark Espie, undeadly.org/cgi?action=article&sid=20070915195203&pid=52 The reason is that the GCC developers pursue other goals than the OpenBSD developers. The difference he shows the following points.
')
(1) GCC is now almost a commercial development. She is engaged in distributors of commercial distributions of Linux and Apple. The compiler targets fast i386 and PowerPC processors only. At the same time, it is honed under the set of high points in SPEC. (From me) As you know, compilation sharpening for certain programs is done in the old-fashioned way - the base of patterns that the compiler must recognize and issue code written for them by humans is simply increasing. Therefore ... (From Mark) But the compiler is getting bigger and bigger, slower and slower, and much more. (From me) What every Gentoo user regrets in the last few years .
(2) The warnings in GCC are useless. Compiling with -Wall reports a lot of things right, and a few incorrect ones.
(3) The whole GCC design is perverted so much that no one can even distinguish the front-end and back-end compilers (from me: the truth is, remember how we dealt with gcc in love trying to teach him to understand non-registered architectures) . It is clumsy, starting with design (broken by design), as the GPL people fear that commercial organizations will be able to steal the backend or frontend and hook them to closed languages or code generators (from me: a strange conclusion, however) . Perhaps this is true. But this does not allow creating interesting tools, such as intermediate code analyzers. And it also does not allow the use of backends for old architectures with new compilers.
(4) As a result, you can’t get new interesting chips from the new version of GCC without losing the old interesting chips (from me: yep, to compile QEMU you still have to carry GCC 3 with you) ... Each GCC update is an engineering nightmare, because that there is no simple choice: you get opportunities, but you lose important features. (From me) Well, in fact, it manifests itself rarely, but if it does, it is really hemorrhoids .
(5) It is also very difficult to develop GCC. Their branching system makes it very likely that important work will disappear between cracks (and this happens all the time). If you are developing code for GCC, you need to do it on the most recent branch, which is quite difficult if your platform is currently inoperable (it happens all the time if you are not under linux / i386) (from me: it probably means that gcc -i686-pc-bsd new version does not work) . Even when you adapt, it is hard to write code in accordance with the GNU coding standards, which are probably the most difficult to read for C. Obviously, they were invented by a lisp programmer. As a result, I (Mark) even lost interest in rewriting and sending several pieces of code to the GCC repository.
(6) Some recent improvements have no chance to work on OpenBSD, for example, pre-assembled includes that rely on mmap () at a fixed address (from me: a strange decision by GCC developers. Was it much more difficult to use the address that mmap returns ( )
(7) There are several places in GCC and G ++ where you cannot get full functionality without having an analogue of glibc (from me: and paranoid OpenBSD's, of course, have no complete analogue of that, because there are many bugs in it) .
(8) Some optimization methods are definitely dangerous and wrong for us (for example, throwing out during memory optimization, even if they deal with crypto keys) (from me: well, yes, it will be bad when your memset (0, 256, & rsakey (the compiler will be thrown out of the code, because there will be no more calls to rsakey. Badly, because another process can get the same physical memory page)
(9) And don't forget the nightmare associated with autoconf / libtool / automake (from me: oh yeah baby). Damn, even the GCCs themselves update the infrastructure for compatibility with the latest automake's for several years. At the same time, GCC is the only ports tree program that actually uses the internal implementation of libtool. Its configuration and reconfiguration collapses completely when you try to use the libtool system.
I (Mark) could actually continue on a few more pages. I have been a GCC Maintainer on OpenBSD for several years and will be happy to switch to another compiler, the path with GCC was so disappointing.
(From me) Here it is, GCC. I had some experience with GCC at the source level, it’s really quiet horror. Although, in recent versions, the code becomes more structured, but porridge is still very much. And it is unlikely to be less, because it is constantly fitting to specific programs. GCC can be compared with other compilers and see how complicated it really is, and how overloaded with template analysis, and not with intellectual optimization. Take at least the same TCC, or PCC. Better yet, look at the jet compilers in Plan9.
So, Linux still has room to grow and strive for.
A few weeks ago, the OpenBSD project announced that the Portable C Compiler was added to the OpenBSD source tree. And developers will try to make it a full replacement for GCC. Why?
')
(1) GCC is now almost a commercial development. She is engaged in distributors of commercial distributions of Linux and Apple. The compiler targets fast i386 and PowerPC processors only. At the same time, it is honed under the set of high points in SPEC. (From me) As you know, compilation sharpening for certain programs is done in the old-fashioned way - the base of patterns that the compiler must recognize and issue code written for them by humans is simply increasing. Therefore ... (From Mark) But the compiler is getting bigger and bigger, slower and slower, and much more. (From me) What every Gentoo user regrets in the last few years .
(2) The warnings in GCC are useless. Compiling with -Wall reports a lot of things right, and a few incorrect ones.
(3) The whole GCC design is perverted so much that no one can even distinguish the front-end and back-end compilers (from me: the truth is, remember how we dealt with gcc in love trying to teach him to understand non-registered architectures) . It is clumsy, starting with design (broken by design), as the GPL people fear that commercial organizations will be able to steal the backend or frontend and hook them to closed languages or code generators (from me: a strange conclusion, however) . Perhaps this is true. But this does not allow creating interesting tools, such as intermediate code analyzers. And it also does not allow the use of backends for old architectures with new compilers.
(4) As a result, you can’t get new interesting chips from the new version of GCC without losing the old interesting chips (from me: yep, to compile QEMU you still have to carry GCC 3 with you) ... Each GCC update is an engineering nightmare, because that there is no simple choice: you get opportunities, but you lose important features. (From me) Well, in fact, it manifests itself rarely, but if it does, it is really hemorrhoids .
(5) It is also very difficult to develop GCC. Their branching system makes it very likely that important work will disappear between cracks (and this happens all the time). If you are developing code for GCC, you need to do it on the most recent branch, which is quite difficult if your platform is currently inoperable (it happens all the time if you are not under linux / i386) (from me: it probably means that gcc -i686-pc-bsd new version does not work) . Even when you adapt, it is hard to write code in accordance with the GNU coding standards, which are probably the most difficult to read for C. Obviously, they were invented by a lisp programmer. As a result, I (Mark) even lost interest in rewriting and sending several pieces of code to the GCC repository.
(6) Some recent improvements have no chance to work on OpenBSD, for example, pre-assembled includes that rely on mmap () at a fixed address (from me: a strange decision by GCC developers. Was it much more difficult to use the address that mmap returns ( )
(7) There are several places in GCC and G ++ where you cannot get full functionality without having an analogue of glibc (from me: and paranoid OpenBSD's, of course, have no complete analogue of that, because there are many bugs in it) .
(8) Some optimization methods are definitely dangerous and wrong for us (for example, throwing out during memory optimization, even if they deal with crypto keys) (from me: well, yes, it will be bad when your memset (0, 256, & rsakey (the compiler will be thrown out of the code, because there will be no more calls to rsakey. Badly, because another process can get the same physical memory page)
(9) And don't forget the nightmare associated with autoconf / libtool / automake (from me: oh yeah baby). Damn, even the GCCs themselves update the infrastructure for compatibility with the latest automake's for several years. At the same time, GCC is the only ports tree program that actually uses the internal implementation of libtool. Its configuration and reconfiguration collapses completely when you try to use the libtool system.
I (Mark) could actually continue on a few more pages. I have been a GCC Maintainer on OpenBSD for several years and will be happy to switch to another compiler, the path with GCC was so disappointing.
(From me) Here it is, GCC. I had some experience with GCC at the source level, it’s really quiet horror. Although, in recent versions, the code becomes more structured, but porridge is still very much. And it is unlikely to be less, because it is constantly fitting to specific programs. GCC can be compared with other compilers and see how complicated it really is, and how overloaded with template analysis, and not with intellectual optimization. Take at least the same TCC, or PCC. Better yet, look at the jet compilers in Plan9.
So, Linux still has room to grow and strive for.
Source: https://habr.com/ru/post/31277/
All Articles