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