June 04, 2002 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Martin M. Pedersen | "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. |
June 04, 2002 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Sean L. Palmer | "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 |
June 10, 2002 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 |
June 10, 2002 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to andy | 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 |
June 10, 2002 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 |
June 10, 2002 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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 |
June 10, 2002 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Walker | "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> |
June 10, 2002 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Andy Walker | 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 |
September 09, 2003 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | 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.
|
September 09, 2003 Re: Study of GCC frontend and Walter's DMD compiler sources] | ||||
---|---|---|---|---|
| ||||
Posted in reply to Carlos Santander B. | | 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 |
Copyright © 1999-2021 by the D Language Foundation