I don't think there will be much possibility to carry over stuff between Watcom and GCC for the following reasons:
1) Carrying over source code between the 2 compilers will not be possible because both compilers are probably using completely different ways of representing the code internally during compilation.
2) In theory, it might be possible to carry over optimization algorithms, but in practice, this may be impossible due to software patents. In fact, a lot of algorithms used in compilers are covered by software patents. GNU because of it's licensing is not allowed to use algorithms that are covered by patents. The only exception is in cases where a manufacturer grants the GNU project the right to use their patents. This has for example been the case with some pantents from IBM which are being used in GCC. Watcom OTOH contains algorithms for which Sybase has the patents and they sure don't want to share these (see their open license text). Also, they will not be able to use the patents used in GCC as they are not part of the GNU project.
So sharing between GCC and OpenWatcom is probably mostly impossible both for technical and for legal reasons.
Marcel
Re:How about the Intel Compiler?
on
GCC 3.2.1 Released
·
· Score: 2, Interesting
I think it's mainly a support issue. The money Intel gets from the compiler is probably used to pay the people that have to support the compiler. Software companies would certainly want to get professional support, and the cost of the compiler is certainly not an issue for them. For those people who pay for the Intel compiler, Intel gives support. If Intel gave away the compiler to everyone, they could not give the same level of support to everyone, and professional users might not be keen to use the compiler without proper support behind it.
I think for the moment, the main problem is that there are no good test suites to test ABI compliance. That's the reason why GCC is currently struggling. They think they have done it correctly, but then from time to time someone notices a new ABI bug. Anyway, the real world test will be when people try to actually link C++ libaries produced by compilers from different companies.
Marcel
Re:How about the Intel Compiler?
on
GCC 3.2.1 Released
·
· Score: 4, Informative
I think one of the main reasons why Intel does not contribute to GCC is not that they want to make money selling their compiler, but rather that they are not satisfied with the results of prior contributions they did to GCC. I might be wrong, but I think Intel contributed to GCC at least twice in the past.
When the Pentium processor was released, Intel was quite dissatisfied by by the performance of the GCC code on Pentium processors, and so they took the GCC source code and made a number of improvements to it to generate much better Pentium code. They than gave back the modifed source code as some igcc compiler or so. This modified GCC compiler was then used as a bases of the PGCC compiler, but they were never really picked up by the GCC project until EGCS became GCC.
Later on, I think Intel sponsored the GCC project to pay a developer to improve Pentium II support, but once again, it took I think something like 2 years until the contributed effort was mirrored in a released GCC version.
So I think that in the end, Intel decided that it was not effficient to contribute to the GCC project as the contributions took too long to show an efffect on actual GCC compilers and this would make newer Intel processors run inefficiently for too long a time on GCC based systems. With their own compilers, Intel themselves are master of the release process, and they can make sure that they have a new compiler at the same time they officially start shipping a new processor generation.
Finally, there is another big hurdle Intel may face. Especially processors like the Itanium and the P4 take a lot of modifications to the compiler to make efficient code. However because GCC has to support a wide range of processors, big architecture changes aren't easy to implement at the risk of breaking compatibility with other processors supported by GCC.
So overall, I think Intel chose to make their own compilers because to them, that is the most efficient approach that guarantees them to have good compilers for new processors in an acceptable time frame.
Marcel
2. You may use the NCP Documentation only for providing technical
support services to end users of Novell products and to support Your
development of Derivative Software that does not: a) enable more than
one end user per copy of the Derivative Software to access a NetWare
server; or, b) provide NetWare server functions.
Actually, I read this as client software development being allowed using this documentation. What is not allowed is using to documentation to write some kind of gateway that would allow multiple users to connect to the server over a single connection, thus bypassing the server licensing, plus the implementation of an NCP server.
Maybe it suprises you, but the documentation for NCP is public already for a couple of years :
http://developer.novell.com/ndk/doc/ncp/ncp__enu/d ata/hc4lztgy.html
Also, current versions of NCPFS do support NCP/IP connections.
Slashdot Mirror
I don't think there will be much possibility to carry over stuff between Watcom and GCC for the following reasons:
1) Carrying over source code between the 2 compilers will not be possible because both compilers are probably using completely different ways of representing the code internally during compilation.
2) In theory, it might be possible to carry over optimization algorithms, but in practice, this may be impossible due to software patents. In fact, a lot of algorithms used in compilers are covered by software patents. GNU because of it's licensing is not allowed to use algorithms that are covered by patents. The only exception is in cases where a manufacturer grants the GNU project the right to use their patents. This has for example been the case with some pantents from IBM which are being used in GCC. Watcom OTOH contains algorithms for which Sybase has the patents and they sure don't want to share these (see their open license text). Also, they will not be able to use the patents used in GCC as they are not part of the GNU project.
So sharing between GCC and OpenWatcom is probably mostly impossible both for technical and for legal reasons.
Marcel
I think it's mainly a support issue. The money Intel gets from the compiler is probably used to pay the people that have to support the compiler. Software companies would certainly want to get professional support, and the cost of the compiler is certainly not an issue for them. For those people who pay for the Intel compiler, Intel gives support. If Intel gave away the compiler to everyone, they could not give the same level of support to everyone, and professional users might not be keen to use the compiler without proper support behind it.
Marcel
Here is some more background information:
. html
1 /msg00002.h tml
References to Intel's early offorts on GCC can be found in the documentation of the PGCC project:
http://www.goof.com/pcg/
In June 1999 the new x86 backend sponsored by Intel was announced on the GCC mailing list:
http://gcc.gnu.org/ml/gcc/1999-06/msg00548
In June 2001, GCC 3.0 which first included the new backend was released:
http://gcc.gnu.org/ml/gcc-announce/200
Marcel
I think for the moment, the main problem is that there are no good test suites to test ABI compliance. That's the reason why GCC is currently struggling. They think they have done it correctly, but then from time to time someone notices a new ABI bug.
Anyway, the real world test will be when people try to actually link C++ libaries produced by compilers from different companies.
Marcel
I think one of the main reasons why Intel does not contribute to GCC is not that they want to make money selling their compiler, but rather that they are not satisfied with the results of prior contributions they did to GCC. I might be wrong, but I think Intel contributed to GCC at least twice in the past. When the Pentium processor was released, Intel was quite dissatisfied by by the performance of the GCC code on Pentium processors, and so they took the GCC source code and made a number of improvements to it to generate much better Pentium code. They than gave back the modifed source code as some igcc compiler or so. This modified GCC compiler was then used as a bases of the PGCC compiler, but they were never really picked up by the GCC project until EGCS became GCC. Later on, I think Intel sponsored the GCC project to pay a developer to improve Pentium II support, but once again, it took I think something like 2 years until the contributed effort was mirrored in a released GCC version. So I think that in the end, Intel decided that it was not effficient to contribute to the GCC project as the contributions took too long to show an efffect on actual GCC compilers and this would make newer Intel processors run inefficiently for too long a time on GCC based systems. With their own compilers, Intel themselves are master of the release process, and they can make sure that they have a new compiler at the same time they officially start shipping a new processor generation. Finally, there is another big hurdle Intel may face. Especially processors like the Itanium and the P4 take a lot of modifications to the compiler to make efficient code. However because GCC has to support a wide range of processors, big architecture changes aren't easy to implement at the risk of breaking compatibility with other processors supported by GCC. So overall, I think Intel chose to make their own compilers because to them, that is the most efficient approach that guarantees them to have good compilers for new processors in an acceptable time frame. Marcel
Sorry, looks like the formatting did not turn out the way I intended it.
2. You may use the NCP Documentation only for providing technical support services to end users of Novell products and to support Your development of Derivative Software that does not: a) enable more than one end user per copy of the Derivative Software to access a NetWare server; or, b) provide NetWare server functions. Actually, I read this as client software development being allowed using this documentation. What is not allowed is using to documentation to write some kind of gateway that would allow multiple users to connect to the server over a single connection, thus bypassing the server licensing, plus the implementation of an NCP server.
Maybe it suprises you, but the documentation for NCP is public already for a couple of years : http://developer.novell.com/ndk/doc/ncp/ncp__enu/d ata/hc4lztgy.html
Also, current versions of NCPFS do support NCP/IP connections.