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:
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)


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
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


used

 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"


work?

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


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


Yes its obvious. But it still represents a challenge.


 - 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.


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






have

 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




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 "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




of

 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




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?


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




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 don't know.


 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.




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




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?


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


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.


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


used

 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


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.


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


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.


 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.


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


problem

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


Fixed.


     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.


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


it

     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"


and

 "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


 What's the issue with recompiling gcc with g++?


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().


 These are all part of the standard C99 spec. I'm a little surprised they


are

 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




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.


 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


them.

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


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.


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




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.
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


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.


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


used

 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


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.


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


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.


 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.


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


problem

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


Fixed.


     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.


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


it

     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"


and

 "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?




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.


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?




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.


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...


<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.


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


<snip>

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


it.

<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