Go compilation model

[Vladimir Panteleev]

On Sat, 14 Nov 2009 11:25:05 +0200, Yigal Chripun <yigal100 at 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 at gmail.com