www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Go compilation model

reply Yigal Chripun <yigal100 gmail.com> writes:
I just saw this on the Go language site
from http://golang.org/cmd/gc/


gives the overall design of the tool chain. Aside from a few adapted 
pieces, such as the optimizer, the Go compilers are wholly new programs.

The compiler reads in a set of Go files, typically suffixed ".go". They 
must all be part of one package. The output is a single intermediate 
file representing the "binary assembly" of the compiled package, ready 
as input for the linker (6l, etc.).

The generated files contain type information about the symbols exported 
by the package and about types used by symbols imported by the package 
from other packages. It is therefore not necessary when compiling client 
C of package P to read the files of P's dependencies, only the compiled 
output of P.

/quote

notice that they removed the need for header files.
Nov 14 2009
parent reply "Vladimir Panteleev" <thecybershadow gmail.com> writes:
On Sat, 14 Nov 2009 11:25:05 +0200, Yigal Chripun <yigal100 gmail.com>  
wrote:


 I just saw this on the Go language site
 from http://golang.org/cmd/gc/


 gives the overall design of the tool chain. Aside from a few adapted  
 pieces, such as the optimizer, the Go compilers are wholly new programs.

 The compiler reads in a set of Go files, typically suffixed ".go". They  
 must all be part of one package. The output is a single intermediate  
 file representing the "binary assembly" of the compiled package, ready  
 as input for the linker (6l, etc.).

 The generated files contain type information about the symbols exported  
 by the package and about types used by symbols imported by the package  
 from other packages. It is therefore not necessary when compiling client  
 C of package P to read the files of P's dependencies, only the compiled  
 output of P.

 /quote

 notice that they removed the need for header files.


I'd like to point out that this is also what Pascal/Delphi have been doing  
for a long while - units (*.pas files) are compiled to compiled units  
(*.tpu for Turbo/Borland Pascal, *.dcu for Delphi) which contain compiled  
code as well as type information. They can probably also contain code in  
an intermediate format, since Delphi allows cross-unit inlining (a  
function must be declared as "inline" in the interface section of the  
unit).

Speaking of inlining, it doesn't look like Go's scheme would allow  
cross-package inlining (not that DMD can do inlining across objects or  
libraries, but LDC could change this).

I assume Go can also read type information from source files, otherwise  
package circular dependencies would be impossible?

-- 
Best regards,
  Vladimir                          mailto:thecybershadow gmail.com
Nov 14 2009
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Vladimir Panteleev wrote:

 I'd like to point out that this is also what Pascal/Delphi have been 
 doing for a long while


Also it's the way Java is implemented.


 I assume Go can also read type information from source files, otherwise 
 package circular dependencies would be impossible?


Java will pick up the type info from either the .class file or the .java 
file.
Nov 14 2009
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Sat, 14 Nov 2009 13:39:54 -0500, Walter Bright  
<newshound1 digitalmars.com> wrote:


 Vladimir Panteleev wrote:

 I'd like to point out that this is also what Pascal/Delphi have been  
 doing for a long while


 Also it's the way Java is implemented.


 I assume Go can also read type information from source files, otherwise  
 package circular dependencies would be impossible?


 Java will pick up the type info from either the .class file or the .java  
 file.


The thing I thought was unique to Go's compiling/linking was the bypassing  
of duplicated imports. i.e. If a imported b and c, and b imported c, then  
compiling a would only link b, since c was included in b's object. They  
claimed exponential-like speed-up doing this. (If memory of the Google  
talk serves.)
Nov 14 2009
parent Walter Bright <newshound1 digitalmars.com> writes:
Robert Jacques wrote:

 The thing I thought was unique to Go's compiling/linking was the 
 bypassing of duplicated imports. i.e. If a imported b and c, and b 
 imported c, then compiling a would only link b, since c was included in 
 b's object. They claimed exponential-like speed-up doing this. (If 
 memory of the Google talk serves.)


I think that's a misunderstanding of Go's process. I think Go's 
compilation process is the same as D's, in that modules only have to be 
parsed/compiled once regardless of how often they are imported.

The C/C++ #include model is an n squared process.
Nov 14 2009