www.digitalmars.com         C & C++   DMDScript  

D - [Fwd: Study of GCC frontend and Walter's DMD compiler sources]

reply "Andrew C. Oliver" <acoliver apache.org> writes:
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Forwarding to main group.  None of my posts to D.gnu come through.
Jun 02 2002
next sibling parent reply Jan Knepper <jan smartsoft.cc> writes:
 I think it would be increadibly difficult to write a GCC front end in
 C++.

Why? The two interface rather well...
 Therefore I think we'll have to port the D front end to straight C
 first, while attemping to parallel Walter's overall object structure.
 Its unfortunate because it would be nice to have a non-divergent
 versions, but I don't think there is an easier way to do it.  Any
 thoughts?  (practical thoughts only please)

I would stay with the current D front end as it is and write a (small) layer to do the interfacing. I have understood from Walter that he has done stuff like that too to interface newer idea's in newer code with the existing code generator, but I could be wrong.
 2. Create an overall framework/coupling for working with the GCC front
 end.  This serves two purposes.  First of all, to isolate us from the
 changing GCC front-end interface.  Second of all, the GCC front end
 stuff is ugly, we should be able to encapsulate it and produce something
 that allows us to manage it at a higher level so that we only have to
 get intimate with it once.  The rest of the time we'll work above it.

That's what I mean, write a conversion layer between the D front end and GCC... Rewriting what has been done and still is in development does not sound like the greatest idea to me.
Jun 02 2002
next sibling parent "anderson" <anderson firestar.com.au> writes:
I agree,
And what happens when Walter makes a change... You may have to rewrite a big
chunk of it.

"Jan Knepper" <jan smartsoft.cc> wrote in message
news:3CFAC302.D8A04FBF smartsoft.cc...
 I think it would be increadibly difficult to write a GCC front end in
 C++.

Why? The two interface rather well...
 Therefore I think we'll have to port the D front end to straight C
 first, while attemping to parallel Walter's overall object structure.
 Its unfortunate because it would be nice to have a non-divergent
 versions, but I don't think there is an easier way to do it.  Any
 thoughts?  (practical thoughts only please)

I would stay with the current D front end as it is and write a (small)

 to do the interfacing.
 I have understood from Walter that he has done stuff like that too to
 interface newer idea's in newer code with the existing code generator, but

 could be wrong.

 2. Create an overall framework/coupling for working with the GCC front
 end.  This serves two purposes.  First of all, to isolate us from the
 changing GCC front-end interface.  Second of all, the GCC front end
 stuff is ugly, we should be able to encapsulate it and produce something
 that allows us to manage it at a higher level so that we only have to
 get intimate with it once.  The rest of the time we'll work above it.

That's what I mean, write a conversion layer between the D front end and GCC... Rewriting what has been done and still is in development does not sound

 the greatest idea to me.

Jun 02 2002
prev sibling parent andy <acoliver apache.org> writes:
Jan Knepper wrote:
I think it would be increadibly difficult to write a GCC front end in
C++.

Why? The two interface rather well...

You do realize It'd be the *first* C++ written GCC front end right? I'm not sure how to do it while fitting into GCC. Take a quick gander at this: http://cobolforgcc.sourceforge.net/cobol_toc.html#TOC48 and the Toy or tree language. See if you still feel like this.
 
 I would stay with the current D front end as it is and write a (small) layer
 to do the interfacing.
 I have understood from Walter that he has done stuff like that too to
 interface newer idea's in newer code with the existing code generator, but I
 could be wrong.
 
 
2. Create an overall framework/coupling for working with the GCC front
end.  This serves two purposes.  First of all, to isolate us from the
changing GCC front-end interface.  Second of all, the GCC front end
stuff is ugly, we should be able to encapsulate it and produce something
that allows us to manage it at a higher level so that we only have to
get intimate with it once.  The rest of the time we'll work above it.

That's what I mean, write a conversion layer between the D front end and GCC... Rewriting what has been done and still is in development does not sound like the greatest idea to me.

Humm. Yes I don't like it, I just am not entirely sure how to do so otherwise. I'll take another look. -Andy
 
 

Jun 03 2002
prev sibling next sibling parent "Sean L. Palmer" <seanpalmer earthlink.net> writes:
I have a gut feeling you are in way over your head.

Sean

"Andrew C. Oliver" <acoliver apache.org> wrote in message
news:3CFAAA3F.2020800 apache.org...
 Forwarding to main group.  None of my posts to D.gnu come through.

Jun 02 2002
prev sibling next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
Hi,

"Andrew C. Oliver" <acoliver apache.org> wrote in message
news:3CFAAA3F.2020800 apache.org...
 Forwarding to main group.  None of my posts to D.gnu come through.

 I think it would be increadibly difficult to write a GCC front end in
 C++.  Therefore I think we'll have to port the D front end to straight C
 first, while attemping to parallel Walter's overall object structure.
 Its unfortunate because it would be nice to have a non-divergent
 versions, but I don't think there is an easier way to do it.  Any
 thoughts?  (practical thoughts only please)

I agree. The problem is that the code will depend on the C++ RTL which GCC probably does not link with. A solution to this is to put the C++ code into a shared library and include the C++ RTL in the shared library and resolve references to that internally. There might be problems initializing the C++ RTL, but that can be overcome. I have used this technique a couple of times. Its not without problems, though. I would prefer a pure C solution, and in any case, we need a solution that does not use features specific to DMC. I have found: - complex_t - Hexadecimal notation of double literals supported by strtod() - Use of strtof() and strtold(). Neither my Windows compiler or GCC have them, and they are not part of x/Open specification either. If strtod() is used in stead of strtold() precision is lost. I don't know it this can be solved. - Use of contracts. I don't know if there are others. If Walter's source, not the documentation, is to be authorative, it would be nice if it could be used as-is. This would allow the source to be easily updated. I have a working lexer, and a partial bison grammar that has all statements and expressions. I've stopped, temporarily anyway, for a number of reasons: - The D specification is incomplete in the sense that it covers all language constructs. For examle, BasicType and BasicType2 are not described. - I ran into conflicts attempting to model the declarations by reverse-engineering Walter's front-end. I may be my fault. - I would like to consider the D specification authorative - not the existing front-end. But I'm not sure if I can. I prefer a bison solution over recursive descent because it allows grammar documentation to be extracted directly from the source. My approach is also a little different from Walter's regarding strings. I use wchar_t's everywhere internally. Some problems I have identified are described below. Don't take me wrong. I think that Walter has been doing a great job, and I hope a list with even the smallet things described will help making it a better product. In http://www.digitalmars.com/d/lex.html : - "synchronized" not listed as keyword - "===" and "!==" are not described as tokens. - "asm", "delegate" are is not described as a keywords. - "volatile" is described as a keyword. However, it is stated in "statement.html" that "D has no volatile storage type". I suspect that way to many keywords are reserved. - Literal grammar uses 0b, not 0x, for hexadecimal literals. So this is wrong: Hexadecimal: 0b HexDigits - It is not specified that 0B and 0X are valid prefixes for literal integers; Only 0b and 0X are described. Case does not matter in "lexer.c". - It is stated: "Floats can be in decimal or hexadecimal notation, as in standard C". Hexadecimal notation is not standard, is it? Is definitely is not standard C++ (not described in ISO/IEC 14882). It expect this will cause some difficulty because the underlying C library does not support hexadecimal notation using strtod(). http://www.digitalmars.com/d/expression.html ShiftExpression: AddExpression AddExpression << AddExpression AddExpression >> AddExpression AddExpression <<< AddExpression The <<< operator is not defined by "lex.html", and "dmd" will not compile it. It is probably a typo, and the operator should be >>>. The same problem exists with <<<= vs. >>>=. In the definition of the ShiftExpression above, AddExpression should be replaced with ShiftExpression on the left side of the operator (in a Bison grammar)The same goes for other binary expression. If not, expressions like a+b+c will not compile. "ArgumentList" is not described. "NewExpression" is not described. The description of variable initialization is ambiguous. It says: IdentifierList: Variable Variable , IdentifierList Variable: Identifier Identifier = Expression "Expression" is a comma separated list of AssignmentExpression's, and it therefore conflicts with IdentifierList. So, Expression should be AssignmentExpression instead (like it is in C). http://www.digitalmars.com/d/statement.html {} is both an EmptyStatement and a BlockStatement. EmptyStatement should not be in the grammar. Synchronize Statement uses the keyword "synchronize". However, the keyword is defined as "synchronized" (with a "d") in both "lexer.c" and "lex.html". How about rethrowing exceptions? The ThrowStatement does not allow throw to be used without an expression: ThrowStatement: throw Expression ; The AsmStatement is described as: AsmStatement: { } { AsmInstructionList } It lacks the "asm" keyword. In http://www.digitalmars.com/d/declaration.html : - BasicType and BasicType2 are not described. - Only const, static, final, synchronized, and deprecated are described as storage specifiers (or whatever it should be called). However, "parser.c" recognizes many more.
Jun 03 2002
next sibling parent reply "Pavel Minayev" <evilone omen.ru> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:adg4i1$1o2s$1 digitaldaemon.com...

 I would prefer a pure C solution, and in any case, we need a solution that
 does not use features specific to DMC. I have found:

 - complex_t

If this is what I think it is, then won't "typedef complex complex_t" work?
 - Hexadecimal notation of double literals supported by strtod()

 - Use of strtof() and strtold(). Neither my Windows compiler or GCC have
 them,
   and they are not part of x/Open specification either. If strtod() is

 in stead
   of strtold() precision is lost. I don't know it this can be solved.

The solution is obvious: write your own versions of these. =)
 - Use of contracts.

Since a bugless program should never ever produce contract violations, and since contracts don't have side-effects, I think you could just strip these away. Or maybe write some macros to imitate DBC in pure C?
 In http://www.digitalmars.com/d/lex.html :

 - "synchronized" not listed as keyword

I remember some others weren't as well. Also, several listed there aren't actually keywords ("ascii").
 - Literal grammar uses 0b, not 0x, for hexadecimal literals.
   So this is wrong:
             Hexadecimal:
               0b HexDigits

Just a mistype.
 - It is stated:
         "Floats can be in decimal or hexadecimal notation, as in standard
 C".
    Hexadecimal notation is not standard, is it? Is definitely is not
 standard
    C++ (not described in ISO/IEC 14882). It expect this will cause
    some difficulty because the underlying C library does not support
    hexadecimal notation using strtod().

Yep, it's not standard. You'll have to write your own conversion utils for it to work.
     How about rethrowing exceptions? The ThrowStatement does not
     allow throw to be used without an expression:
         ThrowStatement:
           throw Expression ;

It doesn't in practice as well. You'll just have to throw the exception you've caught, I guess.
Jun 03 2002
parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
"Pavel Minayev" <evilone omen.ru> wrote in message
news:adg7s3$1rcf$1 digitaldaemon.com...
 "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
 news:adg4i1$1o2s$1 digitaldaemon.com...

 If this is what I think it is, then won't "typedef complex complex_t"

The problem is that there is no complex type defined by the standard to my knowledge. Standard C++ defines it as template. Regarding GCC, I just studied its documentation of its extensions. It seems that it has a __complex__ type that might be used. I also noted that it supports hex floating point literals. So it seems that these issues are not problems after all with GCC. But they still represent portability problems (or challenges :-), generally speaking.
 - Use of strtof() and strtold(). Neither my Windows compiler or GCC have


Yes its obvious. But it still represents a challenge.
 - Use of contracts.

and since contracts don't have side-effects, I think you could just strip these away.

Yes. Another approach could be to put them into #ifdef __DMC__ conditionals. I guess Walter just have forgotten it, as he does use such conditionals elsewhere. Regards, Martin M. Pedersen
Jun 03 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:adgceo$202v$1 digitaldaemon.com...

 The problem is that there is no complex type defined by the standard to my
 knowledge. Standard C++ defines it as template. Regarding GCC, I just

Then use std::complex: typedef std::complex<double> complex; Or that built-in __complex__ type.
 - Use of strtof() and strtold(). Neither my Windows compiler or GCC



 The solution is obvious: write your own versions of these. =)

Yes its obvious. But it still represents a challenge.

Life would be dull without challenges, no? =) Besides, it's not a real challenge, after all... by the way, you might want to take a look at atof() in my math2 module. It works with extended and understands D features like hex floats. I guess one could easily make strtof() and strtold() out of it.
Jun 04 2002
prev sibling next sibling parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:adg4i1$1o2s$1 digitaldaemon.com...
 - It is stated:
         "Floats can be in decimal or hexadecimal notation, as in standard
 C".
    Hexadecimal notation is not standard, is it? Is definitely is not
 standard
    C++ (not described in ISO/IEC 14882). It expect this will cause
    some difficulty because the underlying C library does not support
    hexadecimal notation using strtod().

I don't see why someone couldn't write: -0xfeed.beef // same as -65261.7458343505859375 or 0b10.01 // same as 2.25 although since e is a valid hex char it would require a different form of scientific notation. Sean
Jun 03 2002
parent reply "Sean L. Palmer" <seanpalmer earthlink.net> writes:
Oh and for hex floats, the f suffix would be ambiguous.

Drat, I've done gone and killed my own proposal.  ;(

Sean

"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:adgbl9$1vco$1 digitaldaemon.com...
 "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
 news:adg4i1$1o2s$1 digitaldaemon.com...
 - It is stated:
         "Floats can be in decimal or hexadecimal notation, as in


 C".
    Hexadecimal notation is not standard, is it? Is definitely is not
 standard
    C++ (not described in ISO/IEC 14882). It expect this will cause
    some difficulty because the underlying C library does not support
    hexadecimal notation using strtod().

I don't see why someone couldn't write: -0xfeed.beef // same as -65261.7458343505859375 or 0b10.01 // same as 2.25 although since e is a valid hex char it would require a different form of scientific notation. Sean

Jun 03 2002
parent "Pavel Minayev" <evilone omen.ru> writes:
"Sean L. Palmer" <seanpalmer earthlink.net> wrote in message
news:adhg57$49n$1 digitaldaemon.com...

 I don't see why someone couldn't write:

 -0xfeed.beef // same as -65261.7458343505859375


You can.
 0b10.01  // same as 2.25


You can't =(
 although since e is a valid hex char it would require a different form


 scientific notation.


In hex notation, you use p: 0x8p2 == 8 * 16^2
Jun 04 2002
prev sibling next sibling parent reply andy <acoliver apache.org> writes:
 
 
 I agree. The problem is that the code will depend on the C++ RTL which GCC
 probably does not link with. A solution to this is to put the C++ code into
 a shared library and include the C++ RTL in the shared library and resolve
 references to that internally. There might be problems initializing the C++
 RTL, but that can be overcome. I have used this technique a couple of times.
 Its not without problems, though.
 

Such as? Other than not diverging from Walter's front end as much, what advantages do you see?
 I would prefer a pure C solution, and in any case, we need a solution that

I'm trying not to let my personal preferences get in the way.
 does not use features specific to DMC. I have found:
 
 - complex_t
 
 - Hexadecimal notation of double literals supported by strtod()
 
 - Use of strtof() and strtold(). Neither my Windows compiler or GCC have
 them,
   and they are not part of x/Open specification either. If strtod() is used
 in stead
   of strtold() precision is lost. I don't know it this can be solved.
 
 - Use of contracts.
 
 I don't know if there are others. If Walter's source, not the documentation,
 is to be authorative, it would be nice if it could be used as-is. This would
 allow the source to be easily updated.
 

True. But when does the cost of the GCC pain and troubles exceed that?
 I have a working lexer, and a partial bison grammar that has all statements
 and expressions. I've stopped, temporarily anyway, for a number of reasons:
 - The D specification is incomplete in the sense that it covers all language
 constructs. For examle, BasicType and BasicType2 are not described.

Perhaps we can reconstruct them from the source?
 - I ran into conflicts attempting to model the declarations by
 reverse-engineering Walter's front-end. I may be my fault.
 - I would like to consider the D specification authorative - not the
 existing front-end. But I'm not sure if I can.
 

Can you list all of the deficiencies (or are they all listed below)? I'll do my best to contribute to completing the Spec (running my patches by Walter of course).
 I prefer a bison solution over recursive descent because it allows grammar
 documentation to be extracted directly from the source. My approach is also
 a little different from Walter's regarding strings. I use wchar_t's
 everywhere internally.

Interesting, you don't find the memory consumption arguments compelling?
 
 Some problems I have identified are described below. Don't take me wrong. I
 think that Walter has been doing a great job, and I hope a list with even
 the smallet things described will help making it a better product.
 
 In http://www.digitalmars.com/d/lex.html :
 
 - "synchronized" not listed as keyword
 
 - "===" and "!==" are not described as tokens.
 
 - "asm", "delegate" are is not described as a keywords.
 
 - "volatile" is described as a keyword. However, it is stated in
   "statement.html" that "D has no volatile storage type". I suspect
   that way to many keywords are reserved.
 
 - Literal grammar uses 0b, not 0x, for hexadecimal literals.
   So this is wrong:
             Hexadecimal:
               0b HexDigits
 
 - It is not specified that 0B and 0X are valid prefixes for literal
 integers;
   Only 0b and 0X are described. Case does not matter in "lexer.c".
 
 - It is stated:
         "Floats can be in decimal or hexadecimal notation, as in standard
 C".
    Hexadecimal notation is not standard, is it? Is definitely is not
 standard
    C++ (not described in ISO/IEC 14882). It expect this will cause
    some difficulty because the underlying C library does not support
    hexadecimal notation using strtod().
 
 http://www.digitalmars.com/d/expression.html
 
     ShiftExpression:
       AddExpression
       AddExpression << AddExpression
       AddExpression >> AddExpression
       AddExpression <<< AddExpression
     The <<< operator is not defined by "lex.html", and "dmd" will not
 compile it.
     It is probably a typo, and the operator should be >>>. The same problem
     exists with <<<= vs. >>>=.
 
     In the definition of the ShiftExpression above, AddExpression should be
     replaced with ShiftExpression on the left side of the operator (in a
 Bison
     grammar)The same goes for other binary expression. If not, expressions
     like a+b+c will not compile.
 
     "ArgumentList" is not described.
 
     "NewExpression" is not described.
 
     The description of variable initialization is ambiguous. It says:
         IdentifierList:
           Variable
           Variable , IdentifierList
         Variable:
           Identifier
           Identifier = Expression
     "Expression" is a comma separated list of AssignmentExpression's, and it
     therefore conflicts with IdentifierList. So, Expression should be
     AssignmentExpression instead (like it is in C).
 
 http://www.digitalmars.com/d/statement.html
 
     {} is both an EmptyStatement and a BlockStatement. EmptyStatement
     should not be in the grammar.
 
     Synchronize Statement uses the keyword "synchronize". However, the
     keyword is defined as "synchronized" (with a "d") in both "lexer.c" and
 "lex.html".
 
     How about rethrowing exceptions? The ThrowStatement does not
     allow throw to be used without an expression:
         ThrowStatement:
           throw Expression ;
 
     The AsmStatement is described as:
         AsmStatement:
       { }
       { AsmInstructionList }
     It lacks the "asm" keyword.
 
 In http://www.digitalmars.com/d/declaration.html :
 
 - BasicType and BasicType2 are not described.
 
 - Only const, static, final, synchronized, and deprecated are described
    as storage specifiers (or whatever it should be called). However,
    "parser.c" recognizes many more.
 
 
 

Jun 03 2002
parent "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
"andy" <acoliver apache.org> wrote in message
news:3CFBB3C6.7090803 apache.org...
 A solution to this is to put the C++ code into
 a shared library and include the C++ RTL in the shared library and


 references to that internally. There might be problems initializing the


 RTL, but that can be overcome. I have used this technique a couple of


 Its not without problems, though.

advantages do you see?

The major problem is that even though shared libraries are widely supported, there are also differences in how they are made, and how they work. I have used them on Linux, AIX, Solaris, and HP-UX. They were are all different. So using shared libraries causes portability problems. The major advantage of using Walter's front end, is not diverging. Another advantage, if it can be easily updated, is that Walter does bug fixing :-)
 I don't know if there are others. If Walter's source, not the


 is to be authorative, it would be nice if it could be used as-is. This


 allow the source to be easily updated.

True. But when does the cost of the GCC pain and troubles exceed that?

I don't know.
 For examle, BasicType and BasicType2 are not described.

 - I ran into conflicts attempting to model the declarations by
 reverse-engineering Walter's front-end.


More work on my part will probably help, and more updates to the spec will help too.
 Can you list all of the deficiencies (or are they all listed below)?

They were all listed.
 I prefer a bison solution over recursive descent because it allows


 documentation to be extracted directly from the source. My approach is


 a little different from Walter's regarding strings. I use wchar_t's
 everywhere internally.


Memory consumption does not really bother me. Walter probably knows better, but I don't think the amount of string data used while compiling is significant. I have never experienced the amount of memory used by my compilers to be a problem (except for DOS compilers), so I figured that this would not be a problem either. If it would be, all the symbols would go into a hash table, and in this way keeping only one representation of each symbol used. The same symbols appears again and again, so much could be gained in this way. It also has the advantage that when inserted into the hash table, strings can be compared for equality simply comparing pointers. But the question is: What is gained? Because symbols are all ASCII, there really is no point in doing it this way. Regards, Martin M. Pedersen
Jun 03 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:adg4i1$1o2s$1 digitaldaemon.com...
 I agree. The problem is that the code will depend on the C++ RTL which GCC
 probably does not link with. A solution to this is to put the C++ code

 a shared library and include the C++ RTL in the shared library and resolve
 references to that internally. There might be problems initializing the

 RTL, but that can be overcome. I have used this technique a couple of

 Its not without problems, though.

What's the issue with recompiling gcc with g++?
 I would prefer a pure C solution, and in any case, we need a solution that
 does not use features specific to DMC. I have found:
 - complex_t
 - Hexadecimal notation of double literals supported by strtod()
 - Use of strtof() and strtold(). Neither my Windows compiler or GCC have
 them,
   and they are not part of x/Open specification either. If strtod() is

 in stead
   of strtold() precision is lost. I don't know it this can be solved.

These are all part of the standard C99 spec. I'm a little surprised they are not in gcc. Doesn't gcc support long doubles, if so, isn't there a conversion in the gcc library for it? If not, just use strtod(), that's what I used for bootstrapping myself. One can always go back later and upgrade it.
 - Use of contracts.

Those can just be #ifdef'd out.
 I have a working lexer, and a partial bison grammar that has all

 and expressions. I've stopped, temporarily anyway, for a number of

 - The D specification is incomplete in the sense that it covers all

 constructs. For examle, BasicType and BasicType2 are not described.

What those do is enable both C and D style array declarations to work: int foo[]; int[] foo; both declare foo to be an array of int's.
 I prefer a bison solution over recursive descent because it allows grammar
 documentation to be extracted directly from the source. My approach is

 a little different from Walter's regarding strings. I use wchar_t's
 everywhere internally.

That will work, but since wchar_t's on linux are 4 bytes, I found with another project on linux that it consumed lots of memory and ran slower. I also ran into maddening gaps in gcc's library support for wchar_t's.
 Some problems I have identified are described below. Don't take me wrong.

 think that Walter has been doing a great job, and I hope a list with even
 the smallet things described will help making it a better product.

It's great that you're posting these problems, that enables me to fix them.
 In http://www.digitalmars.com/d/lex.html :
 - "synchronized" not listed as keyword

Yes it is!
 - "===" and "!==" are not described as tokens.

Fixed.
 - "asm", "delegate" are is not described as a keywords.

Fixed.
 - "volatile" is described as a keyword. However, it is stated in
   "statement.html" that "D has no volatile storage type". I suspect
   that way to many keywords are reserved.

volatile is now removed.
 - Literal grammar uses 0b, not 0x, for hexadecimal literals.
   So this is wrong:
             Hexadecimal:
               0b HexDigits

Fixed.
 - It is not specified that 0B and 0X are valid prefixes for literal
 integers;
   Only 0b and 0X are described. Case does not matter in "lexer.c".

Fixed.
 - It is stated:
         "Floats can be in decimal or hexadecimal notation, as in standard
 C".
    Hexadecimal notation is not standard, is it? Is definitely is not
 standard
    C++ (not described in ISO/IEC 14882). It expect this will cause
    some difficulty because the underlying C library does not support
    hexadecimal notation using strtod().

It is in C99, but not in C++98.
 http://www.digitalmars.com/d/expression.html

     ShiftExpression:
       AddExpression
       AddExpression << AddExpression
       AddExpression >> AddExpression
       AddExpression <<< AddExpression
     The <<< operator is not defined by "lex.html", and "dmd" will not
 compile it.
     It is probably a typo, and the operator should be >>>. The same

     exists with <<<= vs. >>>=.

Fixed.
     In the definition of the ShiftExpression above, AddExpression should

     replaced with ShiftExpression on the left side of the operator (in a
 Bison
     grammar)The same goes for other binary expression. If not, expressions
     like a+b+c will not compile.

a+b+c should parse as ((a+b)+c). As long as that works, you should be ok.
     "ArgumentList" is not described.
     "NewExpression" is not described.

I'll add these.
     The description of variable initialization is ambiguous. It says:
         IdentifierList:
           Variable
           Variable , IdentifierList
         Variable:
           Identifier
           Identifier = Expression
     "Expression" is a comma separated list of AssignmentExpression's, and

     therefore conflicts with IdentifierList. So, Expression should be
     AssignmentExpression instead (like it is in C).

Done.
 http://www.digitalmars.com/d/statement.html

     {} is both an EmptyStatement and a BlockStatement. EmptyStatement
     should not be in the grammar.

Fixed.
     Synchronize Statement uses the keyword "synchronize". However, the
     keyword is defined as "synchronized" (with a "d") in both "lexer.c"

 "lex.html".

Fixed.
     How about rethrowing exceptions? The ThrowStatement does not
     allow throw to be used without an expression:
         ThrowStatement:
           throw Expression ;

This has been discussed at length. It's probably a good idea.
     The AsmStatement is described as:
         AsmStatement:
       { }
       { AsmInstructionList }
     It lacks the "asm" keyword.

Fixed.
 In http://www.digitalmars.com/d/declaration.html :

 - BasicType and BasicType2 are not described.

Yes, this needs work.
 - Only const, static, final, synchronized, and deprecated are described
    as storage specifiers (or whatever it should be called). However,
    "parser.c" recognizes many more.

This needs work too.
Jun 03 2002
next sibling parent reply "Martin M. Pedersen" <mmp www.moeller-pedersen.dk> writes:
"Walter" <walter digitalmars.com> wrote in message
news:adgbub$1vgu$1 digitaldaemon.com...

 A solution to this is to put the C++ code into
 a shared library and include the C++ RTL in the shared library


I don't know - it might be that simple. But when I have used the other solution, I did not have that option.
 - complex_t
 - Hexadecimal notation of double literals supported by strtod()
 - Use of strtof() and strtold().


 not in gcc.

Then I have learned something new :-) Looking deeper into this it turns out that it has a __complex__ type, the hex notation is supported, and both strtold() and strtof() can be found in the headers and libraries, but not the man pages). So these does not represent any real problems with GCC after all.
 I prefer a bison solution over recursive descent because it allows


 documentation to be extracted directly from the source. My approach is
 also a little different from Walter's regarding strings. I use wchar_t's
 everywhere internally.

That will work, but since wchar_t's on linux are 4 bytes, I found with another project on linux that it consumed lots of memory and ran slower. I also ran into maddening gaps in gcc's library support for wchar_t's.

Yes, I have noticed such gaps too. I started out using wchar_t's in order to support unicode identifiers and file names. The spec does not specify what a letter in an identifier is, but I see in "lexer.c" that it is [A-Za-z]. I guess that is how it should be - keeping link compability with C.
 It's great that you're posting these problems, that enables me to fix

And you are quick actually doing it too :-) Regards, Martin M. Pedersen
Jun 03 2002
parent reply "Walter" <walter digitalmars.com> writes:
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:adgfa2$23tj$1 digitaldaemon.com...
 Yes, I have noticed such gaps too. I started out using wchar_t's in order

 support unicode identifiers and file names. The spec does not specify what

 letter in an identifier is, but I see in "lexer.c" that it is [A-Za-z]. I
 guess that is how it should be - keeping link compability with C.

While D supports unicode source files, unicode comments, unicode strings, and generating unicode apps, the identifiers are standard C identifiers. This ensures compatibility with existing linkers, librarians, debuggers, disassemblers, etc. Rewriting all of that stuff is way, way beyond the scope of D!
Jun 03 2002
parent reply "Carlos Santander B." <carlos8294 msn.com> writes:
Walter escribió:
 
 While D supports unicode source files, unicode comments, unicode strings,
 and generating unicode apps, the identifiers are standard C identifiers.
 This ensures compatibility with existing linkers, librarians, debuggers,
 disassemblers, etc. Rewriting all of that stuff is way, way beyond the scope
 of D!
 
 

Is there a way to change that? --------------------------- Carlos Santander B.
Sep 08 2003
next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
| Walter escribió:
| >
| > While D supports unicode source files, unicode comments, unicode
strings,
| > and generating unicode apps, the identifiers are standard C identifiers.
| > This ensures compatibility with existing linkers, librarians, debuggers,
| > disassemblers, etc. Rewriting all of that stuff is way, way beyond the
scope
| > of D!

(written on 2002-06-03 14:44, by the way. that'd be june 3th, 2002)

-------------------------
Carlos Santander


---

Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 2003-09-01
Sep 08 2003
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Carlos Santander B." <carlos8294 msn.com> wrote in message
news:bjjfel$2ndu$1 digitaldaemon.com...
 Walter escribió:
 While D supports unicode source files, unicode comments, unicode


 and generating unicode apps, the identifiers are standard C identifiers.
 This ensures compatibility with existing linkers, librarians, debuggers,
 disassemblers, etc. Rewriting all of that stuff is way, way beyond the


 of D!


Not with the resources at my disposal. Sorry.
Sep 08 2003
parent reply Mike Wynn <mike l8night.co.uk> writes:
Walter wrote:
 "Carlos Santander B." <carlos8294 msn.com> wrote in message
 news:bjjfel$2ndu$1 digitaldaemon.com...
 
Walter escribió:

While D supports unicode source files, unicode comments, unicode


strings,
and generating unicode apps, the identifiers are standard C identifiers.
This ensures compatibility with existing linkers, librarians, debuggers,
disassemblers, etc. Rewriting all of that stuff is way, way beyond the


scope
of D!

Is there a way to change that?

Not with the resources at my disposal. Sorry.

isn't utf8 designed for exactly this purpose ? would the linker fail if the ids contained chars 0x80..0xFF ? Java utf8 encoding only uses 0x01..0xFE (or 0xFD [i forget which]) so strings can have embedded nulls and oxFF's but they never appear in the "exported" string.
Sep 09 2003
parent "Walter" <walter digitalmars.com> writes:
"Mike Wynn" <mike l8night.co.uk> wrote in message
news:bjkod7$1jt5$1 digitaldaemon.com...
 isn't utf8 designed for exactly this purpose ?
 would the linker fail if the ids contained chars 0x80..0xFF ? Java utf8
 encoding only uses 0x01..0xFE (or 0xFD [i forget which]) so strings can
 have embedded nulls and oxFF's but they never appear in the "exported"
 string.

The identifier strings will print as garbage, though.
Sep 09 2003
prev sibling parent Andy Walker <Andy_member pathlink.com> writes:
Thank you for all the fixes, Walter.

In article <adgbub$1vgu$1 digitaldaemon.com>, Walter says...
"Martin M. Pedersen" <mmp www.moeller-pedersen.dk> wrote in message
news:adg4i1$1o2s$1 digitaldaemon.com...
 I agree. The problem is that the code will depend on the C++ RTL which GCC
 probably does not link with. A solution to this is to put the C++ code

 a shared library and include the C++ RTL in the shared library and resolve
 references to that internally. There might be problems initializing the

 RTL, but that can be overcome. I have used this technique a couple of

 Its not without problems, though.

What's the issue with recompiling gcc with g++?
 I would prefer a pure C solution, and in any case, we need a solution that
 does not use features specific to DMC. I have found:
 - complex_t
 - Hexadecimal notation of double literals supported by strtod()
 - Use of strtof() and strtold(). Neither my Windows compiler or GCC have
 them,
   and they are not part of x/Open specification either. If strtod() is

 in stead
   of strtold() precision is lost. I don't know it this can be solved.

These are all part of the standard C99 spec. I'm a little surprised they are not in gcc. Doesn't gcc support long doubles, if so, isn't there a conversion in the gcc library for it? If not, just use strtod(), that's what I used for bootstrapping myself. One can always go back later and upgrade it.
 - Use of contracts.

Those can just be #ifdef'd out.
 I have a working lexer, and a partial bison grammar that has all

 and expressions. I've stopped, temporarily anyway, for a number of

 - The D specification is incomplete in the sense that it covers all

 constructs. For examle, BasicType and BasicType2 are not described.

What those do is enable both C and D style array declarations to work: int foo[]; int[] foo; both declare foo to be an array of int's.
 I prefer a bison solution over recursive descent because it allows grammar
 documentation to be extracted directly from the source. My approach is

 a little different from Walter's regarding strings. I use wchar_t's
 everywhere internally.

That will work, but since wchar_t's on linux are 4 bytes, I found with another project on linux that it consumed lots of memory and ran slower. I also ran into maddening gaps in gcc's library support for wchar_t's.
 Some problems I have identified are described below. Don't take me wrong.

 think that Walter has been doing a great job, and I hope a list with even
 the smallet things described will help making it a better product.

It's great that you're posting these problems, that enables me to fix them.
 In http://www.digitalmars.com/d/lex.html :
 - "synchronized" not listed as keyword

Yes it is!
 - "===" and "!==" are not described as tokens.

Fixed.
 - "asm", "delegate" are is not described as a keywords.

Fixed.
 - "volatile" is described as a keyword. However, it is stated in
   "statement.html" that "D has no volatile storage type". I suspect
   that way to many keywords are reserved.

volatile is now removed.
 - Literal grammar uses 0b, not 0x, for hexadecimal literals.
   So this is wrong:
             Hexadecimal:
               0b HexDigits

Fixed.
 - It is not specified that 0B and 0X are valid prefixes for literal
 integers;
   Only 0b and 0X are described. Case does not matter in "lexer.c".

Fixed.
 - It is stated:
         "Floats can be in decimal or hexadecimal notation, as in standard
 C".
    Hexadecimal notation is not standard, is it? Is definitely is not
 standard
    C++ (not described in ISO/IEC 14882). It expect this will cause
    some difficulty because the underlying C library does not support
    hexadecimal notation using strtod().

It is in C99, but not in C++98.
 http://www.digitalmars.com/d/expression.html

     ShiftExpression:
       AddExpression
       AddExpression << AddExpression
       AddExpression >> AddExpression
       AddExpression <<< AddExpression
     The <<< operator is not defined by "lex.html", and "dmd" will not
 compile it.
     It is probably a typo, and the operator should be >>>. The same

     exists with <<<= vs. >>>=.

Fixed.
     In the definition of the ShiftExpression above, AddExpression should

     replaced with ShiftExpression on the left side of the operator (in a
 Bison
     grammar)The same goes for other binary expression. If not, expressions
     like a+b+c will not compile.

a+b+c should parse as ((a+b)+c). As long as that works, you should be ok.
     "ArgumentList" is not described.
     "NewExpression" is not described.

I'll add these.
     The description of variable initialization is ambiguous. It says:
         IdentifierList:
           Variable
           Variable , IdentifierList
         Variable:
           Identifier
           Identifier = Expression
     "Expression" is a comma separated list of AssignmentExpression's, and

     therefore conflicts with IdentifierList. So, Expression should be
     AssignmentExpression instead (like it is in C).

Done.
 http://www.digitalmars.com/d/statement.html

     {} is both an EmptyStatement and a BlockStatement. EmptyStatement
     should not be in the grammar.

Fixed.
     Synchronize Statement uses the keyword "synchronize". However, the
     keyword is defined as "synchronized" (with a "d") in both "lexer.c"

 "lex.html".

Fixed.
     How about rethrowing exceptions? The ThrowStatement does not
     allow throw to be used without an expression:
         ThrowStatement:
           throw Expression ;

This has been discussed at length. It's probably a good idea.
     The AsmStatement is described as:
         AsmStatement:
       { }
       { AsmInstructionList }
     It lacks the "asm" keyword.

Fixed.
 In http://www.digitalmars.com/d/declaration.html :

 - BasicType and BasicType2 are not described.

Yes, this needs work.
 - Only const, static, final, synchronized, and deprecated are described
    as storage specifiers (or whatever it should be called). However,
    "parser.c" recognizes many more.

This needs work too.

Andy Walker
Jun 09 2002
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
Could GCC simply be compiled with the g++ compiler, rather than gcc? That
would then make it easy to interface D's C++ front end to GCC's C.
Jun 03 2002
next sibling parent reply andy <acoliver apache.org> writes:
Walter wrote:
 Could GCC simply be compiled with the g++ compiler, rather than gcc? That
 would then make it easy to interface D's C++ front end to GCC's C.
 
 
 
 

Cost / benefit analysis -- Here are disadvantages: 1. We'd never get into the GCC standard distribution that way. I'm not sure if we want that, but wider adoption for D would certainly result from default inclusion. 2. We'd forever be *out of sync* with the GCC folks. 3. The GCC folks would think us odd and probably not work very closely with us. 4. Supporting a divergent version of GCC might be a massive undertaking 5. I bet this would be a lot of work. 6. There are no C++ examples of GCC Front ends (or existing front ends written in C++ that I know of). We'd be on our own. Advantages: 1. Resist the effort of rewriting the D Front end in C 2. The D community is largely composed of C++ advocates who might be more likely to contribute with a C++ effort. Anything I missed? -Andy I changed CC=gcc to CC=g++ then did make clean bootstrap this is what I got: (the same thing works with gcc) -------------- if [ x"" != x ]; then \ g++ -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-3.0/libiberty/../include -W -Wa ll -Wtraditional -pedantic ../../gcc-3.0/libiberty/argv.c -o pic/argv.o; \ else true; fi g++ -c -DHAVE_CONFIG_H -g -O2 -I. -I../../gcc-3.0/libiberty/../include -W -Wall -Wtraditional -pedantic ../../gcc-3.0/libiberty/argv.c ../../gcc-3.0/libiberty/argv.c:90: `argv' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:91: `char ** dupargv' redeclared as different kin d of symbol ../../gcc-3.0/libiberty/../include/libiberty.h:38: previous declaration of `char ** dupargv(char **)' ../../gcc-3.0/libiberty/argv.c:91: syntax error before `char' ../../gcc-3.0/libiberty/argv.c:96: parse error before `if' ../../gcc-3.0/libiberty/argv.c:100: `argc' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:100: syntax error before `!=' ../../gcc-3.0/libiberty/argv.c:100: syntax error before `++' ../../gcc-3.0/libiberty/argv.c:101: warning: ANSI C++ forbids declaration `copy' with no type ../../gcc-3.0/libiberty/argv.c:101: conflicting types for `int copy' ../../gcc-3.0/libiberty/argv.c:94: previous declaration as `char ** copy' ../../gcc-3.0/libiberty/argv.c:101: `argc' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:102: parse error before `if' ../../gcc-3.0/libiberty/argv.c:106: `argc' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:106: syntax error before `!=' ../../gcc-3.0/libiberty/argv.c:106: syntax error before `++' ../../gcc-3.0/libiberty/argv.c:109: `argc' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:109: warning: ANSI C++ forbids declaration `copy' with no type ../../gcc-3.0/libiberty/argv.c:109: `len' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:109: assignment (not initialization) in declarati on ../../gcc-3.0/libiberty/argv.c:110: parse error before `if' ../../gcc-3.0/libiberty/argv.c:115: `argc' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:115: `argv' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:115: `argc' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:115: warning: ANSI C++ forbids declaration `strcp y' with no type ../../gcc-3.0/libiberty/argv.c:115: `int strcpy' redeclared as different kind of symbol /usr/include/string.h:33: previous declaration of `char * strcpy(char *, const c har *)' ../../gcc-3.0/libiberty/argv.c:115: warning: initializer list being treated as c ompound expression ../../gcc-3.0/libiberty/argv.c:116: parse error before `}' ../../gcc-3.0/libiberty/argv.c:117: `argc' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:117: warning: ANSI C++ forbids declaration `copy' with no type ../../gcc-3.0/libiberty/argv.c:117: assignment (not initialization) in declarati on ../../gcc-3.0/libiberty/argv.c:118: parse error before `return' ../../gcc-3.0/libiberty/argv.c:144: `vector' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:145: variable or field `freeargv' declared void ../../gcc-3.0/libiberty/argv.c:145: `int freeargv' redeclared as different kind of symbol ../../gcc-3.0/libiberty/../include/libiberty.h:33: previous declaration of `void freeargv(char **)' ../../gcc-3.0/libiberty/argv.c:145: syntax error before `char' ../../gcc-3.0/libiberty/argv.c:151: syntax error before `!=' ../../gcc-3.0/libiberty/argv.c:151: syntax error before `++' ../../gcc-3.0/libiberty/argv.c:155: `vector' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:155: warning: ANSI C++ forbids declaration `free' with no type ../../gcc-3.0/libiberty/argv.c:155: `int free' redeclared as different kind of s ymbol /usr/include/stdlib.h:67: previous declaration of `void free(void *)' ../../gcc-3.0/libiberty/argv.c:156: parse error before `}' ../../gcc-3.0/libiberty/argv.c:206: `input' was not declared in this scope ../../gcc-3.0/libiberty/argv.c:207: `char ** buildargv' redeclared as different kind of symbol ../../gcc-3.0/libiberty/../include/libiberty.h:29: previous declaration of `char ** buildargv(char *)' ../../gcc-3.0/libiberty/argv.c:207: syntax error before `char' ../../gcc-3.0/libiberty/argv.c:219: parse error before `if' ../../gcc-3.0/libiberty/argv.c:237: warning: ANSI C++ forbids declaration `nargv ' with no type ../../gcc-3.0/libiberty/argv.c:237: conflicting types for `int nargv' ../../gcc-3.0/libiberty/argv.c:217: previous declaration as `char ** nargv' ../../gcc-3.0/libiberty/argv.c:237: warning: initialization to `int' from `char **' lacks a cast ../../gcc-3.0/libiberty/argv.c:238: parse error before `}' ../../gcc-3.0/libiberty/argv.c:242: warning: ANSI C++ forbids declaration `nargv ' with no type ../../gcc-3.0/libiberty/argv.c:242: redefinition of `int nargv' ../../gcc-3.0/libiberty/argv.c:237: `int nargv' previously defined here ../../gcc-3.0/libiberty/argv.c:242: warning: initialization to `int' from `char **' lacks a cast ../../gcc-3.0/libiberty/argv.c:242: multiple initializations given for `nargv' ../../gcc-3.0/libiberty/argv.c:243: parse error before `}' ../../gcc-3.0/libiberty/argv.c:249: warning: ANSI C++ forbids declaration `argv' with no type ../../gcc-3.0/libiberty/argv.c:249: conflicting types for `int argv' ../../gcc-3.0/libiberty/argv.c:216: previous declaration as `char ** argv' ../../gcc-3.0/libiberty/argv.c:249: warning: converting NULL to non-pointer type ../../gcc-3.0/libiberty/argv.c:250: parse error before `}' ../../gcc-3.0/libiberty/argv.c:253: warning: ANSI C++ forbids declaration `argv' with no type ../../gcc-3.0/libiberty/argv.c:253: redefinition of `int argv' ../../gcc-3.0/libiberty/argv.c:249: `int argv' previously defined here ../../gcc-3.0/libiberty/argv.c:254: warning: ANSI C++ forbids declaration `argv' with no type ../../gcc-3.0/libiberty/argv.c:254: warning: ANSI C++ forbids variable-size arra y `argv' ../../gcc-3.0/libiberty/argv.c:254: variable-size type declared outside of any f unction ../../gcc-3.0/libiberty/argv.c:254: conflicting types for `int argv[2]' ../../gcc-3.0/libiberty/argv.c:253: previous declaration as `int argv' ../../gcc-3.0/libiberty/argv.c:254: invalid initializer ../../gcc-3.0/libiberty/argv.c:255: parse error before `}' ../../gcc-3.0/libiberty/argv.c:257: warning: ANSI C++ forbids declaration `arg' with no type ../../gcc-3.0/libiberty/argv.c:257: warning: initialization to `int' from `char *' lacks a cast ../../gcc-3.0/libiberty/argv.c:258: parse error before `while' ../../gcc-3.0/libiberty/argv.c:269: syntax error before `++' ../../gcc-3.0/libiberty/argv.c:312: syntax error before `++' ../../gcc-3.0/libiberty/argv.c:315: warning: ANSI C++ forbids declaration `arg' with no type ../../gcc-3.0/libiberty/argv.c:315: conflicting types for `int * arg' ../../gcc-3.0/libiberty/argv.c:257: previous declaration as `int arg' ../../gcc-3.0/libiberty/argv.c:316: warning: ANSI C++ forbids declaration `argv' with no type ../../gcc-3.0/libiberty/argv.c:316: warning: ANSI C++ forbids variable-size arra y `argv' ../../gcc-3.0/libiberty/argv.c:316: variable-size type declared outside of any f unction ../../gcc-3.0/libiberty/argv.c:316: redefinition of `int argv[2]' ../../gcc-3.0/libiberty/argv.c:254: `int argv[2]' previously defined here ../../gcc-3.0/libiberty/argv.c:316: invalid initializer ../../gcc-3.0/libiberty/argv.c:317: parse error before `if' ../../gcc-3.0/libiberty/argv.c:320: warning: ANSI C++ forbids declaration `argv' with no type ../../gcc-3.0/libiberty/argv.c:320: conflicting types for `int argv' ../../gcc-3.0/libiberty/argv.c:316: previous declaration as `int argv[2]' ../../gcc-3.0/libiberty/argv.c:320: warning: converting NULL to non-pointer type ../../gcc-3.0/libiberty/argv.c:321: parse error before `break' ../../gcc-3.0/libiberty/argv.c:323: syntax error before `++' ../../gcc-3.0/libiberty/argv.c:324: warning: ANSI C++ forbids declaration `argv' with no type ../../gcc-3.0/libiberty/argv.c:324: warning: ANSI C++ forbids variable-size arra y `argv' ../../gcc-3.0/libiberty/argv.c:324: variable-size type declared outside of any f unction ../../gcc-3.0/libiberty/argv.c:324: conflicting types for `int argv[2]' ../../gcc-3.0/libiberty/argv.c:320: previous declaration as `int argv' ../../gcc-3.0/libiberty/argv.c:324: invalid initializer ../../gcc-3.0/libiberty/argv.c:326: parse error before `while' ../../gcc-3.0/libiberty/argv.c: In function `void __static_initialization_and_de struction_0(int, int)': cc1plus.exe: register name not specified for `((anonymous))' ../../gcc-3.0/libiberty/argv.c:242: Internal compiler error in `make_decl_rtl', at varasm.c:739 Please submit a full bug report. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. make[1]: *** [argv.o] Error 1 make[1]: Leaving directory `/cygdrive/d/andy/homestuff/d/gcc-3.0-obj/libiberty' make: *** [all-libiberty] Error 2
Jun 03 2002
next sibling parent reply "Walter" <walter digitalmars.com> writes:
"andy" <acoliver apache.org> wrote in message
news:3CFBB141.7080909 apache.org...
 Walter wrote:
 Could GCC simply be compiled with the g++ compiler, rather than gcc?


 would then make it easy to interface D's C++ front end to GCC's C.

Here are disadvantages: 1. We'd never get into the GCC standard distribution that way. I'm not sure if we want that, but wider adoption for D would certainly result from default inclusion.

The fact that apparantly nobody has already done this with GCC is discouraging.
 2. We'd forever be *out of sync* with the GCC folks.

That's a serious problem.
 3. The GCC folks would think us odd and probably not work very closely
 with us.

They probably will anyway <g>.
 Advantages:

 1. Resist the effort of rewriting the D Front end in C
 2. The D community is largely composed of C++ advocates who might be
 more likely to contribute with a C++ effort.

Is g++ written in C, too?
Jun 03 2002
next sibling parent andy <acoliver apache.org> writes:
Here are disadvantages:
1. We'd never get into the GCC standard distribution that way.  I'm not
sure if we want that, but wider adoption for D would certainly result
from default inclusion.

The fact that apparantly nobody has already done this with GCC is discouraging.

yes.
 
2. We'd forever be *out of sync* with the GCC folks.

That's a serious problem.

yes.
 
3. The GCC folks would think us odd and probably not work very closely
with us.

They probably will anyway <g>.

Very true, but I'm sure they thought the Cobol front end folks were weird, but yet I see some collaboration there.
 
Advantages:

1. Resist the effort of rewriting the D Front end in C
2. The D community is largely composed of C++ advocates who might be
more likely to contribute with a C++ effort.

Is g++ written in C, too?

You bet it is. For irony look at the $GCC_ROOT/gcc/cp/Class.c ;-).
 

Jun 03 2002
prev sibling parent Andy Walker <Andy_member pathlink.com> writes:
In article <adgch0$203k$1 digitaldaemon.com>, Walter says...
"andy" <acoliver apache.org> wrote in message
news:3CFBB141.7080909 apache.org...
 Walter wrote:
 Could GCC simply be compiled with the g++ compiler, rather than gcc?


 would then make it easy to interface D's C++ front end to GCC's C.

Here are disadvantages: 1. We'd never get into the GCC standard distribution that way. I'm not sure if we want that, but wider adoption for D would certainly result from default inclusion.

The fact that apparantly nobody has already done this with GCC is discouraging.

This is a direct result of the GCC philosophy: simple portability to darn near everything. There seems to be a KRC compiler everywhere, for free. For C++, they are all different from each other, often even different from other versions from the same vendor. That makes maintaining a generic compiler a nightmare.
 2. We'd forever be *out of sync* with the GCC folks.

That's a serious problem.
 3. The GCC folks would think us odd and probably not work very closely
 with us.

They probably will anyway <g>.
 Advantages:

 1. Resist the effort of rewriting the D Front end in C
 2. The D community is largely composed of C++ advocates who might be
 more likely to contribute with a C++ effort.

Is g++ written in C, too?

Yes. Not only yes, but yes: KRC. Andy Walker
Jun 09 2002
prev sibling parent reply Andy Walker <Andy_member pathlink.com> writes:
In article <3CFBB141.7080909 apache.org>, andy says...

Here are disadvantages:

1. We'd never get into the GCC standard distribution that way.  I'm not 
sure if we want that, but wider adoption for D would certainly result 
from default inclusion.

This is the only reason I really want to develop a Bright D frontend for GCC in the first place.
2. We'd forever be *out of sync* with the GCC folks.

That would not bother me, one way or the other. I am not part of their religion. I have my own.
3. The GCC folks would think us odd and probably not work very closely 
with us.

I sort of take that as a given.
4. Supporting a divergent version of GCC might be a massive undertaking

Yes.
5. I bet this would be a lot of work.

I believe this qualifies as a very literal understatement.
6. There are no C++ examples of GCC Front ends (or existing front ends 
written in C++ that I know of).  We'd be on our own.

Very much so.
Advantages:

1. Resist the effort of rewriting the D Front end in C

The economic comparison is between rewriting DMD to C, versus rewriting the GNU backend into C++. I prefer the former. I am not sure the latter is even possible. There is a reason why the serial port handler for Windows is still written for a 16 bit machine: it still works.
2. The D community is largely composed of C++ advocates who might be 
more likely to contribute with a C++ effort.

There is an old saying in the American South. "We never brings a cake. I bring a cake." Help would be wonderful, but it is unrealistic to count on it.
Anything I missed?

-Andy

Andy Walker
Jun 09 2002
next sibling parent "Walter" <walter digitalmars.com> writes:
"Andy Walker" <Andy_member pathlink.com> wrote in message
news:ae1hij$1pmn$1 digitaldaemon.com...
 There is an old saying in the American South.  "We never brings a cake.  I
 bring a cake."  Help would be wonderful, but it is unrealistic to count on

<g>
Jun 10 2002
prev sibling parent andy <acoliver apache.org> writes:
Andy Walker wrote:
 In article <3CFBB141.7080909 apache.org>, andy says...
 
 <snip>
 
Here are disadvantages:

1. We'd never get into the GCC standard distribution that way.  I'm not 
sure if we want that, but wider adoption for D would certainly result 

from default inclusion.

This is the only reason I really want to develop a Bright D frontend for GCC in the first place.

exactly.
 
2. We'd forever be *out of sync* with the GCC folks.

That would not bother me, one way or the other. I am not part of their religion. I have my own.

Right, the issue being that being in step makes inclusion easier and maintenance nicer and a higher chance of cooperation.
 
3. The GCC folks would think us odd and probably not work very closely 
with us.

I sort of take that as a given.

I'm not quite as sure.
5. I bet this would be a lot of work.

I believe this qualifies as a very literal understatement.

definitely.
1. Resist the effort of rewriting the D Front end in C

The economic comparison is between rewriting DMD to C, versus rewriting the GNU backend into C++. I prefer the former. I am not sure the latter is even possible. There is a reason why the serial port handler for Windows is still written for a 16 bit machine: it still works.

agreed.
 
2. The D community is largely composed of C++ advocates who might be 
more likely to contribute with a C++ effort.

There is an old saying in the American South. "We never brings a cake. I bring a cake." Help would be wonderful, but it is unrealistic to count on it.

Yes... (I hail from Carolina). But I envision this a bit more like a pot luck or pig pickin' -Andy
 
Anything I missed?

-Andy

<snip> Andy Walker

Jun 10 2002
prev sibling parent Andy Walker <Andy_member pathlink.com> writes:
In article <adg4t2$1obg$2 digitaldaemon.com>, Walter says...
Could GCC simply be compiled with the g++ compiler, rather than gcc? That
would then make it easy to interface D's C++ front end to GCC's C.

I don't think so. GCC is not even ISO C. It is intentionally written to be compiled by Kernighan and Ritchie C (KRC). The purpose is to make the GCC compilable by as many systems as possible, and darn near everything has a KRC compiler somewhere, for free. Andy Walker
Jun 09 2002