Where will llvm/clang take FreeBSD?

For FreeBSD's recent development, the most striking, most promising, and most fascinating thing is that llvm/clang will be introduced in a future version. What is this? Why is it worth looking forward? Please listen to me.

Llvm/Clang is a compiler. llvm is something similar to a virtual machine (www.llvm.org). This virtual machine is not a Java or Python VM. The purpose of llvm is not to run but to compile and generate code. That is to say, this llvm is the back-end of the compiler. Clang, (clang.llvm.org) is simply the front end of llvm, a C language family. Its responsibility is to translate the C language into intermediate code recognized by llvm, then, the compilation code of the specific architecture is generated by the llvm backend. Finally, the assembler and connector in the system generate the executable files under a certain architecture.

To be honest, isn't any compiler just like this? It is divided into front-end backend, code generation, and code optimization,
What is the difference between llvm? The most important thing is that llvm provides a function library and a set of well-defined interfaces, which makes the front-end design of the compiler Quite dumb. We can write a front-end of llvm for Perl, which can compile and run the binary code at a cost. It can compile a front-end for python. Do not think how complicated the front-end is. It is not very difficult to use llvm's reasonable interface.

So in general, the llvm/clang architecture is better than the GCC architecture (in fact, writing a GCC language front-end is not a big deal, but you must understand the internal mechanisms and details of GCC, it cannot call several library functions like llvm to handle the problem .), With this advantage, FreeBSD is ready to migrate to llvm/clang. How is it possible? Don't be naive. It is not easy to migrate a large operating system to another development compiler. The reason for doing so is that GNU turns the GCC developed in the future
Since gplv3, BSD has never caught a cold on GPL. This V3 affects the core interests of companies that use FreeBSD for commercial operation. In fact, if a commercial company that uses FreeBSD is willing to contribute to FreeBSD (indeed, it has contributed a lot), llvm/clang will not be able to introduce FreeBSD base for a long time, And llvm
/Clang itself can still make great strides. However, people always only want to get what they don't want to pay. The only consideration for a business company to do things is whether there is any benefit in doing things. Therefore, llvm/clang should not be practical in the near future, although FreeBSD SVN has the clangbsd project.

Someone has also proposed a Unix source base which can only have C language programs, so FreeBSD only need PCC (http://pcc.ludd.ltu.se /).
PCC is also a compiler for installing new wine in the old pot. It is a research version of UNIX compiler, and someone modified and rewritten it again later, it becomes a typical C compiler with two passes and supports the c99 standard. This cannot be entered into FreeBSD. In fact, C ++ cannot be avoided in the current industry (llvm/Clang is written in C ++, clang must provide comprehensive support for C ++. Otherwise, clang cannot Bootstrap itself .), Unless an Ideal operating system, like plan9, is well designed, it has not been accepted by the public for more than 20 years. To make a UNIX system use only the C language, just like letting China go the socialist path, OK? Of course, the reality is impossible. Second use
No one is willing to compile FreeBSD in PCC. I also called on the mailling list to say what PCC can be used. What a classic and how simple it is, you just don't want to modify a makefile or view a line of code. Hi .. People, in this nature, the ox is blowing, and it is best for people to do things. (BTW: always want to modify FreeBSD msdosfs to support the UTF-8 of the Chinese file name, is never done, in fact, is to wait for others to do or allow me to find an excuse-busy ah !! Token)

The revolution is still optimistic, so I believe llvm/clang will eventually enter FreeBSD's base. At that time, after we installed FreeBSD, the first thing we had to do was install the latest GCC in ports. Because a large number of ports software is non-GCC and cannot be compiled, of course some simple software can be compiled using clang, such as shell/bash (I tried, the compiled executable files are smaller than those compiled by GCC, but the compilation time is longer than that of GCC, so the execution performance is unknown ).

The revolution must also recognize the nature of the people. If you want to completely break away from the GNU Compiler family in recent years, it is unlikely. Llvm/Clang is a C/C ++ compiler. Finally, you must use the assembler and connector in the system to generate executable files. In FreeBSD, these as and LD can be GNU. Although BSD's binutils has been developed for a long time, apart from the Development of AR, nm and other things, As and LD are estimated to be eight characters missing a glimpse. Of course, I also understand that some of them are used first. Why bother rebuilding the wheel for licence? For
It is estimated that the llvm project will come out by itself, as if it is called "MC" (it is also heard that people are playing on the mailling list). As for linker, although it is not a complicated software, it is estimated that the linker of BSD will be visible only after GNU turns its LD into gplv3.

Finally, where will the new compiler take FreeBSD? I can't take it with me (I admit that I am a title party ...), It is not just a compiler. Besides, it is not practical in the near future. But FreeBSD-8 is more attractive new things, new tty layer, enhanced kernel SMP, ule, gaint lock further removal, especially the removal of gaint lock in the network stack, I am waiting for the performance test report of the FB-8, it is estimated that in the case of multiple CPUs, the performance of the network stack to the top grade! There is also a new USB code (I don't think there is anything wrong with the old Code, the new Code is estimated to be an improvement in the architecture, but I haven't looked at it yet ..), Increasing the kernel memory limit on amd64 makes it even more difficult to use ZFS. New
The ahci (SATA) driver enters the cam subsystem and finally treats SATA as SCSI (is it lagging behind Linux? It doesn't matter. We only use stable things ).