Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| From: | Kaz Kylheku <157-073-9834@kylheku.com> |
| Newsgroups: | comp.compilers |
| Date: | Sat, 10 Nov 2018 04:20:00 +0000 (UTC) |
| Organization: | Aioe.org NNTP Server |
| References: | 18-05-009 18-11-001 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="86514"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | design |
| Posted-Date: | 10 Nov 2018 23:10:48 EST |
On 2018-11-09, rockbrentwood@gmail.com <rockbrentwood@gmail.com> wrote:
> On Tuesday, May 22, 2018 at 12:39:07 PM UTC-5, Michael Justice wrote:
>> Is there any preference to writing a compiler in say c instead of say
>> java, fortran, basic etc? I ask cause i see many of the projects using
>> either c or c++ instead of other programming languages.
>>
>> nullCompiler
>> [Mostly people use what they're used to, or in languages that are easy
>> to bootstrap on the machines they want to use.
>
> A test of whether the language, itself, is worth using -- assuming it is a
> general purpose language -- is whether you'd be willing to write the compiler,
> itself, in it! I put up a branch (and heavily recoded) version of cparse on my
> machine, which is in C and has 3 layers of self-bootstrapping. GCC has several
> layers of self-bootstrpping, depending on what you implement from it (and
> distressingly, it has -- as of version 6 -- acquired *dependencies* on
> libraries further upstream! That's a major no no!)
A nice bootstrapping method is to build an interpreter for the language
also in some widely available language (like C). The compiler can be
executed by the interpreter to compile itself, plus any other run-time
support code also written in that language.
If the compiler produces that widely-used systems programming language,
then it can just be redistributed in compiled form and an interpreter
need not be included.
That's a tough way to evolve the language, though. An interpreter gives
you a version of the language that is immune to bootstrapping
chicken-egg problems and provides a reference model for what compiled
code should be doing.
You can always revert to the interpreter when things go horribly wrong.
When you make modifications to the compiler and they are so wrong they
break the compiler, you don't have to revert them. Just blow off all
the compiled materials, try too fix your work in the compiler and just
bootstrap from scratch through the stable interpreter. You never need
a last-known-good copy of the compiler in your workspace.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.