4 ms·
System programs can be in user space for instance a run time for another language. As for a compiler ideally its easy to port as its kinda of the bed rock to g
by anfilt 6y ago
System programs can be in user space for instance a run time for another language.
As for a compiler ideally its easy to port as its kinda of the bed rock to get any other system going. Although a compiler for some architecture or use cases is too large to be self hosted or does not make sense to be self hosted. So its not always a deal breaker for a compiler.
- ncmncm 6y agoYou seem to be confused about what C++ and C are, and even about what Gcc is and its relationship to programs it compiles. C++ is a language defined by ISO committee SC22/WG21 via the Standards 14882, most recently C++20 (superseding C++17). C is defined by SC22/WG14, in the same way. The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although MS's [until recently implemented] a long-superceded C Standard), and are, in fact, themselves C++ programs. Portability of compilers is not needed, in general, to "get a system going", because cross-compilation is a mature and long-supported technique. Gcc is very frequently ported anyway, for practical reasons, via cross-compilation. Being coded in C++, and capable of compiling and cross-compiling itself, Gcc remains quite portable, as is repeatedly demonstrated by notedly frequent ports. It is hard to imagine what could be considered a "deal-breaker" in this context. By the evidence, portability of C++ is never a dealbreaker as implementation language for a compiler, as in fact the compilers actually used in "get[ting] any other system going" are, with only rare exceptions, compilers in fact coded in C++. (Exceptions are found not to be about portability, but about the memory footprint of the resulting compiler, which is not a product of its source language, but rather of the power of the compiler's optimizer, which is not always seen as necessary.) In any case, the implementation language used for the compiler has absolutely no effect on the stability of an ABI for any target language. ABI stability is a choice made by language designers to favor backward link-compatibility over convenient expression of new features or bug fixes. It is hard for me to imagine the level of confusion that would produce this error.
- pjmlp 6y ago> although MS's implements a long-superceded C Standard). Not anymore, as of 2020, MVSC supports C11 and C17, with the exception of the C99 features that were dropped in C11, like VLAs. Previously they were only keeping up with the ISO C features required by ISO C++ compatibility requirements.
- eru 6y ago> The most widely used implementations of these Standards -- Gcc, Clang, and MSVC -- are in fact the same project in each case (although MS's [until recently implemented] a long-superceded C Standard), and are, in fact, themselves C++ programs. Yes. Though as far as suitability for 'systems programming' is concerned they might as well be Python programs or bash scripts, as long as they produce suitable output in an adequate amount of time.
- eru 6y ago> System programs can be in user space for instance a run time for another language. OK, I can live with that definition. But what does it have to do with the language you write your compiler in?