Digital Mars - D.gnu - gcc generalities

↑ ↓ ← → "Philippe Elie" <phil.el wanadoo.fr> writes:

apologize for my poor english ...

An attempt to clarify things about gcc:

GCC compiler is a core compiler + a certain number of
front end, the C compiler is for historical reason in the
core compiler directory. There is not point in gcc which
forbid to use a front-end to build another front-end. g++
use this trick and is always compiled from the newly created
gcc C compiler so on, from recent gcc distribution, the C++
front-end is written in ISO C rather in K&R C. Actually there is
no attempt to use a front-end other than the C compiler itself
but you can write a front-end in C++, and compile it through
the newly compiled c++ compiler. That's "just" need trickery in
configure/makefile (and indeed you can't get only the Core+C
minimal distribution). Actualy this is used in many part of gcc,
mainly for library, (a part of the java runtime is written in C++ ;).
It allows to create portable compiler which, at start of build
process, only assume it exist a vaguely K&R or ISO compliant
compiler installed

About the tree RTL generation: The Run Time Language is the
portable data struct which must describe the program being
to be compiled. Because the RTL is already used in C/C++/ada
/java/PASCAL there is probably no point to create new RTL
expressions for D. I mean than I hope that D does not contains
any things that can't be expressed in the other language given
above ? That's one of the first point which needs to be checked.

You need also a shell script/unix basic tools/Makefile wizard,
configuration/Makefile models of gcc are not easy to understand.

What about the gcc compiler version you want to use to start this
work ? 3.1 compiler has been released a few time ago, 2.95.3 is
probably the most used actually, 3.0 compiler will probably become
the most used in one year.

If you want also the front-end acceptable in future for inclusion in
a gcc distributions you need to comply with the GNU standards
coding, to prove than the language is usefull (used but a sufficiently
number of people, apologize for the lack of precision about "sufficiently
number of") and indeed the front end must be GPL'ed.

The licence terms of the D specifications is perhaps a problem

"Copyright (c) 1999-2002 by Digital Mars, All Rights Reserved"

Is this means than the document which describe D is copyrighted
or the specifications themself are copyrighted ? (I'm newbie
on copyright things ...)

Note than at the point of your current work I think it's better than D
specifications can be modified only by one person but, in futur,
many people can get a bad feeling to work if specifications
are closed.

regards,
Philippe Elie

Jun 10 2002

↑ ↓ ← → andy <acoliver apache.org> writes:

Philippe Elie wrote:
 apologize for my poor english ...
 
 An attempt to clarify things about gcc:
 
 GCC compiler is a core compiler + a certain number of
 front end, the C compiler is for historical reason in the
 core compiler directory. There is not point in gcc which
 forbid to use a front-end to build another front-end. g++
 use this trick and is always compiled from the newly created
 gcc C compiler so on, from recent gcc distribution, the C++
 front-end is written in ISO C rather in K&R C. Actually there is
 no attempt to use a front-end other than the C compiler itself
 but you can write a front-end in C++, and compile it through
 the newly compiled c++ compiler. That's "just" need trickery in
 configure/makefile (and indeed you can't get only the Core+C
 minimal distribution). Actualy this is used in many part of gcc,
 mainly for library, (a part of the java runtime is written in C++ ;).
 It allows to create portable compiler which, at start of build
 process, only assume it exist a vaguely K&R or ISO compliant
 compiler installed


Money where your mouth is.  Show me an example.  Its conjecture until
I see an example of a C++ front end somewhere.

 About the tree RTL generation: The Run Time Language is the
 portable data struct which must describe the program being
 to be compiled. Because the RTL is already used in C/C++/ada
 /java/PASCAL there is probably no point to create new RTL
 expressions for D. I mean than I hope that D does not contains
 any things that can't be expressed in the other language given
 above ? That's one of the first point which needs to be checked.
 
 You need also a shell script/unix basic tools/Makefile wizard,
 configuration/Makefile models of gcc are not easy to understand.
 
 What about the gcc compiler version you want to use to start this
 work ? 3.1 compiler has been released a few time ago, 2.95.3 is
 probably the most used actually, 3.0 compiler will probably become
 the most used in one year.
 


I'd prefer to aim for 3.1 with the idea that by the time we're 
finished...  Otherwise 2.95.3 or 3.0 will be obsolecent by the time we 
and D are done.

 If you want also the front-end acceptable in future for inclusion in
 a gcc distributions you need to comply with the GNU standards
 coding, to prove than the language is usefull (used but a sufficiently
 number of people, apologize for the lack of precision about "sufficiently
 number of") and indeed the front end must be GPL'ed.
 
 The licence terms of the D specifications is perhaps a problem
 
 "Copyright (c) 1999-2002 by Digital Mars, All Rights Reserved"
 
 Is this means than the document which describe D is copyrighted
 or the specifications themself are copyrighted ? (I'm newbie
 on copyright things ...)


The specification AFAIK is closed, the front end is GPL or Artistic 
license. (dual)

Shouldn't be a problem.

-Andy

 Note than at the point of your current work I think it's better than D
 specifications can be modified only by one person but, in futur,
 many people can get a bad feeling to work if specifications
 are closed.
 
 regards,
 Philippe Elie

Jun 10 2002

↑ ↓ ← → Andy Walker <Andy_member pathlink.com> writes:

In article <ae30b2$h63$1 digitaldaemon.com>, Philippe Elie says...
apologize for my poor english ...


As far as I am concerned, you do not need to aplogize.  I am from the U.S., 
and I have not yet learned "proper" English.

An attempt to clarify things about gcc:

GCC compiler is a core compiler + a certain number of
front end, the C compiler is for historical reason in the
core compiler directory. There is not point in gcc which
forbid to use a front-end to build another front-end. g++
use this trick and is always compiled from the newly created
gcc C compiler so on, from recent gcc distribution, the C++
front-end is written in ISO C rather in K&R C. Actually there is
no attempt to use a front-end other than the C compiler itself
but you can write a front-end in C++, and compile it through
the newly compiled c++ compiler. That's "just" need trickery in
configure/makefile (and indeed you can't get only the Core+C
minimal distribution). Actualy this is used in many part of gcc,
mainly for library, (a part of the java runtime is written in C++ ;).
It allows to create portable compiler which, at start of build
process, only assume it exist a vaguely K&R or ISO compliant
compiler installed

About the tree RTL generation: The Run Time Language is the
portable data struct which must describe the program being
to be compiled. Because the RTL is already used in C/C++/ada
/java/PASCAL there is probably no point to create new RTL
expressions for D. I mean than I hope that D does not contains
any things that can't be expressed in the other language given
above ? That's one of the first point which needs to be checked.


I am so sure of this that I did not bother to think about it.  There is 
nothing really fancy or sophisticated about Bright D.  Instead, it is a 
simple and solid approach, doing the things that should have been done
twenty years ago.

You need also a shell script/unix basic tools/Makefile wizard,
configuration/Makefile models of gcc are not easy to understand.


I can usually figure out this kind of thing.  My code is usually not 
very elegant, but it works.

What about the gcc compiler version you want to use to start this
work ? 3.1 compiler has been released a few time ago, 2.95.3 is
probably the most used actually, 3.0 compiler will probably become
the most used in one year.


Yes, I know 3.1 is brand new.  I prefer to try to hook up to it.  Time is 
a very scarce resource, and I do not have time to try to hook Bright D to 
the 2.95.3 version.

If you want also the front-end acceptable in future for inclusion in
a gcc distributions you need to comply with the GNU standards
coding, to prove than the language is usefull (used but a sufficiently
number of people, apologize for the lack of precision about "sufficiently
number of") and indeed the front end must be GPL'ed.


I think "sufficiently number of people" is exactly precise.

The licence terms of the D specifications is perhaps a problem

"Copyright (c) 1999-2002 by Digital Mars, All Rights Reserved"

Is this means than the document which describe D is copyrighted
or the specifications themself are copyrighted ? (I'm newbie
on copyright things ...)


I have some idea about how they work.  It will require us persuading 
Walter to sign an assignment for the front end that he has already 
released.  I think he knows that.  That is why he released the front
end without the back end.  Perfectly reasonable as far as I am 
concerned.  

Note than at the point of your current work I think it's better than D
specifications can be modified only by one person but, in futur,
many people can get a bad feeling to work if specifications
are closed.


Linux seems to be working very well, having gone for years with the 
specifications in the hands of just one person.  

PERL has done will by Larry Wahl, as well.  

As for me, I am not much impressed with the products of committees.

regards,
Philippe Elie


Andy Walker

Jun 11 2002

↑ ↓ ← → "Matthew Wilson" <dm synesis-group.com> writes:

Agreed, we keep all the overhead and responsibility with Walter, and then
just get him to do things via a potent combination of guilt and pride. Love
it!

"Andy Walker" <Andy_member pathlink.com> wrote in message
news:ae4cp2$1u39$1 digitaldaemon.com...
 In article <ae30b2$h63$1 digitaldaemon.com>, Philippe Elie says...
apologize for my poor english ...


 As far as I am concerned, you do not need to aplogize.  I am from the


 and I have not yet learned "proper" English.

An attempt to clarify things about gcc:

GCC compiler is a core compiler + a certain number of
front end, the C compiler is for historical reason in the
core compiler directory. There is not point in gcc which
forbid to use a front-end to build another front-end. g++
use this trick and is always compiled from the newly created
gcc C compiler so on, from recent gcc distribution, the C++
front-end is written in ISO C rather in K&R C. Actually there is
no attempt to use a front-end other than the C compiler itself
but you can write a front-end in C++, and compile it through
the newly compiled c++ compiler. That's "just" need trickery in
configure/makefile (and indeed you can't get only the Core+C
minimal distribution). Actualy this is used in many part of gcc,
mainly for library, (a part of the java runtime is written in C++ ;).
It allows to create portable compiler which, at start of build
process, only assume it exist a vaguely K&R or ISO compliant
compiler installed

About the tree RTL generation: The Run Time Language is the
portable data struct which must describe the program being
to be compiled. Because the RTL is already used in C/C++/ada
/java/PASCAL there is probably no point to create new RTL
expressions for D. I mean than I hope that D does not contains
any things that can't be expressed in the other language given
above ? That's one of the first point which needs to be checked.


 I am so sure of this that I did not bother to think about it.  There is
 nothing really fancy or sophisticated about Bright D.  Instead, it is a
 simple and solid approach, doing the things that should have been done
 twenty years ago.

You need also a shell script/unix basic tools/Makefile wizard,
configuration/Makefile models of gcc are not easy to understand.


 I can usually figure out this kind of thing.  My code is usually not
 very elegant, but it works.

What about the gcc compiler version you want to use to start this
work ? 3.1 compiler has been released a few time ago, 2.95.3 is
probably the most used actually, 3.0 compiler will probably become
the most used in one year.


 Yes, I know 3.1 is brand new.  I prefer to try to hook up to it.  Time is
 a very scarce resource, and I do not have time to try to hook Bright D to
 the 2.95.3 version.

If you want also the front-end acceptable in future for inclusion in
a gcc distributions you need to comply with the GNU standards
coding, to prove than the language is usefull (used but a sufficiently
number of people, apologize for the lack of precision about "sufficiently
number of") and indeed the front end must be GPL'ed.


 I think "sufficiently number of people" is exactly precise.

The licence terms of the D specifications is perhaps a problem

"Copyright (c) 1999-2002 by Digital Mars, All Rights Reserved"

Is this means than the document which describe D is copyrighted
or the specifications themself are copyrighted ? (I'm newbie
on copyright things ...)


 I have some idea about how they work.  It will require us persuading
 Walter to sign an assignment for the front end that he has already
 released.  I think he knows that.  That is why he released the front
 end without the back end.  Perfectly reasonable as far as I am
 concerned.

Note than at the point of your current work I think it's better than D
specifications can be modified only by one person but, in futur,
many people can get a bad feeling to work if specifications
are closed.


 Linux seems to be working very well, having gone for years with the
 specifications in the hands of just one person.

 PERL has done will by Larry Wahl, as well.

 As for me, I am not much impressed with the products of committees.

regards,
Philippe Elie


 Andy Walker

Jun 12 2002

↑ ↓ ← → Charles Hixson <charleshixsn earthlink.net> writes:

Andy Walker wrote:
 ...
 
 Linux seems to be working very well, having gone for years with the 
 specifications in the hands of just one person.  
 
 PERL has done will by Larry Wahl, as well.  


Python and Ruby have also done well with one person in charge.  Eiffel 
has been less spectacularlly successful, though it has a nice 
theoretical excellence.

OTOH, we have C, C++, Cobol, Ada, Fortran, ...

Both sides have successes and failures.  The languages with a single 
chief designer seem to maintain a more central and simple vision, but 
the products of committees tend to be more encompassing. 
(Theoretically, this is silly, as they are all complete languages.  In 
practice, however...)

 
 As for me, I am not much impressed with the products of committees.
 
 
regards,
Philippe Elie

Nov 01 2002