www.digitalmars.com         C & C++   DMDScript  

D - Translator instead of compiler?

reply Russ Lewis <russ deming-os.org> writes:
I'm wondering if it wouldn't be easier - and would facilitate quicker
adoption of the language - if the first implementation of D was a
translator, not a compiler.  Many C compilers, for example, do not
compile directly to machine code; the compile to assembly language and
let an assembler create the machine code.

D could be done similarly; you could write a command-line translator (in
ANSI C) that would translate a set of D modules down to a single massive
C source file (or maybe a set of C source files).  Then we could
leverage existing C compiler technology to create binaries.

This would allow a single implementation to immediately be ported to all
platforms.

Later, we could work on a dedicated D compiler or a gcc frontend.
Aug 17 2001
next sibling parent reply "Dave Nebinger" <dnebinger riteaid.com> writes:
Just the effort of creating this translator means that you have the lexical,
syntactical, and semantice analyzers completed; you've completed most of the
work of a full D compiler.  Whether you then take the time to translate into
another language or spit out some object code is (IMHO) the same amount of
work (perhaps more to complete the translation).  So when you get that far
you might as well finish it the right way...

Would translating into C and/or C++ have a positive or negative effect on
language acceptance?  If anything, I'd guess negative (increased build times
to translate from one language to another).

Dave Nebinger
dnebinger riteaid.com
Aug 17 2001
next sibling parent Russ Lewis <russ deming-os.org> writes:
Dave Nebinger wrote:

 Just the effort of creating this translator means that you have the lexical,
 syntactical, and semantice analyzers completed; you've completed most of the
 work of a full D compiler.  Whether you then take the time to translate into
 another language or spit out some object code is (IMHO) the same amount of
 work (perhaps more to complete the translation).  So when you get that far
 you might as well finish it the right way...

True, the hard work of the compiler is already done. However, since the structure of the language closely mirrors C, I suspect that it would be *much* easier to spit out C code (especially unreadable, poorly formatted C code) than it would be to create assembler. Also, the the "code-generator" needs to be re-implemented (and re-tested) on EVERY platform, rather than just once. I suspect that the real work of writing a compiler or translator would not be in writing it, but in testing it to confirm conformance to the spec. That is far easier, I would guess, with translator as compared to a full compiler.
 Would translating into C and/or C++ have a positive or negative effect on
 language acceptance?  If anything, I'd guess negative (increased build times
 to translate from one language to another).

Yes, it would increase build times. But it would reduce time-to-market, meaning that the process of acceptance can start sooner. I fully expect that full, native, optimized and optimizing D compilers (try pronouncing that w/o confusion) will come out later.
Aug 17 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Dave Nebinger wrote in message <9lji2j$1n07$1 digitaldaemon.com>...
Would translating into C and/or C++ have a positive or negative effect on
language acceptance?  If anything, I'd guess negative (increased build

to translate from one language to another).

I implemented the first native C++ compiler. Before then, C++ was a translator put out by AT&T. Other C extensions were popular, like ObjectiveC, and there was no indication that C++ was going to win out over the others. Others may remember history a little differently <g>, but as I recall C++ just was not popular as a translator. Compiles were too slow, debuggers didn't support it, and the difficulties dealing with the vagaries of the back end C compilers of the day were endlessly frustrating. The first Zortech C++ flew out the door <g>. All of a sudden, despite it being a rather primitive C++ compared to today, programmers had a fast, inexpensive, integrated C++ compiler. Interest in the language zoomed. The success of Zortech C++ is what inspired other major language vendors to do C++ compilers of their own, and by then, C++ was established as a major language here to stay. So, while I claim no credit for the design of C++, I do claim some role in the early establishment of C++ as a major language rather than a curiosity. It's also the basis for my figuring that a native implementation is needed.
Aug 17 2001
next sibling parent reply Russ Lewis <russ deming-os.org> writes:
Walter wrote:

 So, while I claim no credit for the design of C++, I do claim some role in
 the early establishment of C++ as a major language rather than a curiosity.
 It's also the basis for my figuring that a native implementation is needed.

Fair enough. Can you, then, give a guesstimate how much more/less work it is to make a compiler as compared to a translator? Would a translator get out the door faster, and be a good demonstration/standard setting mechanism, or would it take nearly as long as a full compiler? Frankly, after reading that somebody with real compiler experience is actually looking into D, I'm itching to use this language *soon*. :) It would make some of my projects SO much easier!
Aug 17 2001
parent reply "Walter" <walter digitalmars.com> writes:
Russ Lewis wrote in message <3B7D817E.B453B499 deming-os.org>...
Walter wrote:
 So, while I claim no credit for the design of C++, I do claim some role


 the early establishment of C++ as a major language rather than a


 It's also the basis for my figuring that a native implementation is


Fair enough.  Can you, then, give a guesstimate how much more/less work it

to make a compiler as compared to a translator?  Would a translator get out

door faster, and be a good demonstration/standard setting mechanism, or

it take nearly as long as a full compiler?

Given an existing back end, it is easier to connect to that than generate C. Making a full optimizer/code generator is *far* more work than generating C. One nice fallout with D is that since it is so easy to lex, parse, etc., it is going to be a smokin' fast compiler. <g>
Frankly, after reading that somebody with real compiler experience is

looking into D, I'm itching to use this language *soon*.  :)  It would make
some of my projects SO much easier!

Well, I'm itching to use it too! It's (of course) the language I always wanted, but nobody else made. In my experiments with it, it helps me get my own work done much faster.
Aug 17 2001
parent reply "Kent Sandvik" <sandvik excitehome.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:9lk2ce$2bo3$1 digitaldaemon.com...
 Given an existing back end, it is easier to connect to that than generate

 Making a full optimizer/code generator is *far* more work than generating

 One nice fallout with D is that since it is so easy to lex, parse, etc.,

 is going to be a smokin' fast compiler. <g>

Would the front end be initially written in D? Always hard to boot strap, but it would speed up things concerning implementation issues. --Kent
Aug 17 2001
parent "Walter" <walter digitalmars.com> writes:
Kent Sandvik wrote in message <9lk3ga$2chc$1 digitaldaemon.com>...
"Walter" <walter digitalmars.com> wrote in message
news:9lk2ce$2bo3$1 digitaldaemon.com...
 Given an existing back end, it is easier to connect to that than generate

 Making a full optimizer/code generator is *far* more work than generating

 One nice fallout with D is that since it is so easy to lex, parse, etc.,

 is going to be a smokin' fast compiler. <g>

Would the front end be initially written in D? Always hard to boot strap, but it would speed up things concerning implementation issues. --Kent

Because it's bootstrapped, it's in C++.
Aug 17 2001
prev sibling parent reply Russell Bornschlegel <kaleja estarcion.com> writes:
Walter wrote:
 
 Dave Nebinger wrote in message <9lji2j$1n07$1 digitaldaemon.com>...
Would translating into C and/or C++ have a positive or negative effect on
language acceptance?  If anything, I'd guess negative (increased build

to translate from one language to another).

I implemented the first native C++ compiler. Before then, C++ was a translator put out by AT&T.

Minor nit: Not that it hurts any of the other points you make here (in fact, it supports your points about performance), but IIRC, Stroustrup goes to some lengths in _Design and Evolution..._ to explain that Cfront wasn't a 'mere translator'[1], but a full-blown compiler that used C as the target language instead of assembly or machine language. Zortech would thus be 'the first C++ compiler to target machine-native object code', or something awkward like that. :) -Russell B [1] All compilers are 'translators', but Cfront doesn't merely rewrite C++ into C. In particular, all compile-time errors are supposed to be caught be Cfront, rather than the backend.
Aug 17 2001
parent "Walter" <walter digitalmars.com> writes:
Russell Bornschlegel wrote in message <3B7D9302.AF5F8B9F estarcion.com>...
Walter wrote:
 I implemented the first native C++ compiler. Before then, C++ was a
 translator put out by AT&T.

Not that it hurts any of the other points you make here (in fact, it supports your points about performance), but IIRC, Stroustrup goes to some lengths in _Design and Evolution..._ to explain that Cfront wasn't a 'mere translator'[1], but a full-blown compiler that used C as the target language instead of assembly or machine language. Zortech would thus be 'the first C++ compiler to target machine-native object code', or something awkward like that. :)

Bjarne's legitimate complaint in the 80's was that people dismissed cfront as just a "preprocessor". It was not a preprocessor (in the sense of a text preprocessor), but a compiler. I don't remember anyone at the time dissing it as a "mere" translator. I agree with Bjarne that successful translators must be real compilers - but they are not *native* compilers. Translators required the addition of a full blown C compiler. Bjarne's strategy of making cfront a translator made C++ quickly available on a wide variety of platforms. AT&T's generous policy of letting others make implementations was crucial. I remember writing a letter to AT&T's lawyers asking them if I could call my product "C++", since AT&T owned the name. (They said yes!) I wish I could find that letter, it would be a nice bit of memorabilia. I don't think anyone else ever asked!
Aug 17 2001
prev sibling next sibling parent Russ Lewis <russ deming-os.org> writes:
Russ Lewis wrote:

 D could be done similarly; you could write a command-line translator (in
 ANSI C) that would translate a set of D modules down to a single massive
 C source file (or maybe a set of C source files).  Then we could
 leverage existing C compiler technology to create binaries.

Addendums: * Since C types have varying sizes, you might have to use typedefs or some such to get ints of the right sizes. That means that the translator won't technically be 100% portable, but the logic could be... (Similar issues with translating aligned D structures into C) * Going to C means you'll likely lose some of the optimizations that D allows.
Aug 17 2001
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
It originally started out that way. The trouble started in when some D
concepts just were not easilly expressed in C. The try-catch-finally is a
case in point. -Walter

Russ Lewis wrote in message <3B7D350E.FB941F8A deming-os.org>...
I'm wondering if it wouldn't be easier - and would facilitate quicker
adoption of the language - if the first implementation of D was a
translator, not a compiler.  Many C compilers, for example, do not
compile directly to machine code; the compile to assembly language and
let an assembler create the machine code.

D could be done similarly; you could write a command-line translator (in
ANSI C) that would translate a set of D modules down to a single massive
C source file (or maybe a set of C source files).  Then we could
leverage existing C compiler technology to create binaries.

This would allow a single implementation to immediately be ported to all
platforms.

Later, we could work on a dedicated D compiler or a gcc frontend.

Aug 17 2001
parent reply Russ Lewis <russ deming-os.org> writes:
Walter wrote:

 It originally started out that way. The trouble started in when some D
 concepts just were not easilly expressed in C. The try-catch-finally is a
 case in point. -Walter

I'm not a compiler writer, so I don't understand. It would seem (from the outside) like a simple goto would work...why does this fail?
Aug 17 2001
parent reply "Walter" <walter digitalmars.com> writes:
Russ Lewis wrote in message <3B7D7ED9.56FA2E1C deming-os.org>...
Walter wrote:

 It originally started out that way. The trouble started in when some D
 concepts just were not easilly expressed in C. The try-catch-finally is a
 case in point. -Walter

I'm not a compiler writer, so I don't understand. It would seem (from the outside) like a simple goto would work...why does this fail?

Implementing exceptions needs back end support. This just isn't there in C. There are wretched ways to do it, but I really don't want to implement a wretched compiler <g>.
Aug 17 2001
parent Russ Lewis <russ deming-os.org> writes:
Walter wrote:

 Russ Lewis wrote in message <3B7D7ED9.56FA2E1C deming-os.org>...
Walter wrote:

 It originally started out that way. The trouble started in when some D
 concepts just were not easilly expressed in C. The try-catch-finally is a
 case in point. -Walter

I'm not a compiler writer, so I don't understand. It would seem (from the outside) like a simple goto would work...why does this fail?

Implementing exceptions needs back end support. This just isn't there in C. There are wretched ways to do it, but I really don't want to implement a wretched compiler <g>.

*& #$ #$% Fair enough. C++ might be able to do it (somewhat), but C++ implementation, in my limited experience, is not very consistent :(
Aug 17 2001