Self-hosted compilers are interesting from the standpoint of "eat your own dogfood". For example, I wonder if OpenMP implementations would be better if compiler authors were forced to parallelize the guts of their compilers with OpenMP :-)
On the other hand, one should choose the right tool for the right purpose. Compilers are different applications from solving PDEs. One would never write a compiler in Fortran, at least since C has existed, because Fortran is not a good language for system software, and a compiler often depends upon those features. Another example of not eating dogfood is that many Linux kernel developers actually use Macs. This is because OS development should always be sandboxed in a VM anyways, and Macs are a much shinier, friend-impressing platform within which to host VMs :-) Jeff On Fri, Oct 16, 2015 at 4:39 AM, Michael Ferguson <[email protected]> wrote: > Hi Russel - > > On 10/16/15, 4:46 AM, "Russel Winder" <[email protected]> wrote: > > >Hi, > > > >Is there an intention to move to using modern C++ for the Chapel > >implementation, C++11 or C++14? The current C++ code I am looking at is > >seeming very 1990s. > > > >Is there any intention to become a self-hosting compiler by rewriting > >Chapel in Chapel? > > These are interesting questions. I'll give my answer, but others might > want to elaborate further. > > First, about modern C++, the Chapel runtime is C (mostly) so that at least > it's possible for target architectures that only support C to build and > run Chapel programs. (In that case you would need to compile your Chapel > programs on a system that had C++ support). > > I think we have some plans (but I'm not sure when) to moving to supporting > C11 atomics and complex numbers in the runtime. I think that some of the > C++11/C11 threading features will be useful to us in the runtime going > forward. > > > For the compiler itself, which is where most of our C++ code is, it's not > so clear to me how C++11 helps us. Note that when building a Chapel > compiler with LLVM support (for extern block support or for LLVM code > generation), we already require C++11 because the LLVM project made it a > requirement. In any case we don't make very heavy use of the C++ features > that I view C++11 as improving the most. (as you said, very 1990s). > > * the compiler mostly uses its own strategy for memory management (sort > of AST node garbage collection betwene passes), so things like > unique_ptr/shared_ptr don't seem so important > * we don't do much with templates or function objects. (At least not > yet). So the C++11 lambdas don't really offer an immediate > improvement. > * the compiler itself is single-threaded, so C++11's much better support > for multi-threading isn't immediately useful to us. > > > I think that as we think about how to improve our compiler's architecture > and AST representations, we will consider C++11. We could probably make > use of auto declarations or the new hash table support. > > > Regarding making a self-hosted compiler - I think making the compiler > self-hosting is an interesting idea and is technically appealing to me. > However, it pretty much means rewriting the compiler and I don't see how > it would help Chapel users in the short term. Another detail is that as > far as I know, to make a self-hosting compiler you need to keep around > anon-self-hosting compiler/interpreter. Some projects just use an earlier > version of the compiler and others have a compiler or interpreter for a > reduced-functionality subset of the language. If there is any benefit to > making a self-hosting Chapel compiler, I think it is in exercising more of > the language. But that benefit is diminished if the compiler is not using > the same subset of the language as everybody else... > > > > > Cheers, > > > -michael > > > > ------------------------------------------------------------------------------ > _______________________________________________ > Chapel-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/chapel-developers > -- Jeff Hammond [email protected] http://jeffhammond.github.io/
------------------------------------------------------------------------------
_______________________________________________ Chapel-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/chapel-developers
