[go-nuts] Go compiler - questions about escape analysis.

[messi...@gmail.com]

Hi,

I'm reading the go compiler source code and now come to the escape analysis 
part,  I just can't figured out the following question so I want to get 
some help from the community:

What's the meaning of location.transient 
?
  I 
can't fully understand the comment of this field, could someone please give 
me an example to explain the meaning of "the represented expression's 
address does not outlive the statement; that is, whether its storage can be 
immediately reused"?  

Thanks for any help and tips.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5b8c56ed-e20e-43b4-ab53-9acfd505240dn%40googlegroups.com.

Re: [go-nuts] Go compiler - syntax tree vs AST?

[messi...@gmail.com]

>  I don't know of a way to dump the former, but perhaps there is one.

It seems there's no way to dump the former tree through any compiler flag 
by now. The dumper entry point is Fdum 
p
 
but one can only use it through UT. Maybe it's only for internal use for 
compiler developers.

>  As far as I know the most likely next evolutionary step in this area 
will be to replace the Node tree with the cmd/compile/internal/syntax tree.

Really? I see in master branch, all the Node tree related code has been 
moved to a separated package* ir(cmd/compile/internal/ir/)*, and a lot of 
work has been done for this change. Do you mean the compiler will use only 
one kind of Syntax Tree and this part of code will be eliminated in the end?

Thanks.
On Monday, May 17, 2021 at 10:49:28 AM UTC+8 spencer...@gmail.com wrote:

> > As far as I know the most likely next evolutionary step in this area 
> will be to replace the Node tree with the cmd/compile/internal/syntax tree.
> hello All, 
>   I have a question. As far as I know, the AST transformation phase has 
> been in existence for several years now. So I want to know the reason why the 
> AST transformation phase has not been eliminated now? 
>
>   Thanks in advance.
> 在2019年9月3日星期二 UTC+8 下午11:37:58 写道：
>
>> Hello Ian,
>>
>> Thank you for your answer.
>>
>> Why do you ask? 
>>
>>
>> Just out of curiosity, I was working with the SSA package for a tool, and 
>> since the compiler uses this package as well I wanted to go a bit deeper on 
>> that and write a small article on it. That's quite an interesting part but 
>> the usage of two different syntax tree was a bit confusing.
>>
>> Hope this helps
>>
>>
>> Yes, a lot. Thanks again!
>>
>> Le mardi 3 septembre 2019 17:54:38 UTC+4, Ian Lance Taylor a écrit :
>>>
>>> On Tue, Sep 3, 2019 at 6:23 AM Vincent Blanchon 
>>>  wrote: 
>>> > 
>>> > The compiler documentation mentions a syntax tree in the parsing phase 
>>> when the AST transformation phase mentions a conversion from the syntax 
>>> tree to the compiler's AST representation. 
>>> > If I do not misunderstand, the command "go tool compile -W" will 
>>> display the AST. 
>>> > 
>>> > I was wondering how far is different the syntax tree from the AST? 
>>> Where could I get documentation or an example of this syntax tree? 
>>>
>>> Note that AST just means Abstract Syntax Tree, so it's a little 
>>> confusing to talk converting a syntax tree to an AST.  What we really 
>>> have is two different ASTs. 
>>>
>>> Unfortunately none of this stuff is well documented.  The parser 
>>> generates a syntax tree as defined in cmd/compile/internal/syntax. 
>>> That is then converted to the Node tree defined in 
>>> cmd/compile/internal/gc/syntax.go.  The -W option dumps the latter.  I 
>>> don't know of a way to dump the former, but perhaps there is one. 
>>>
>>> > Also, is this syntax tree mandatory? Is it not possible to build the 
>>> AST directly from the lexer+parser? 
>>>
>>> The use of two different syntax trees is entirely historical due to 
>>> the evolution of the compiler.  The original code base was a C 
>>> compiler written in C which became a Go compiler written in C which 
>>> was machine translated from C to Go.  There has been a lot of cleanup 
>>> but there is still a lot of historical cruft.  As far as I know the 
>>> most likely next evolutionary step in this area will be to replace the 
>>> Node tree with the cmd/compile/internal/syntax tree. 
>>>
>>> Hope this helps, and I hope someone will correct me if I made a mistake. 
>>>
>>> Why do you ask? 
>>>
>>> Ian 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2e2c488c-1cc3-4072-b01c-e0c11a09eb13n%40googlegroups.com.

Re: [go-nuts] Need help/tips on golang compiler souce code reading

[messi...@gmail.com]

Hi,

Now I've finished the package types2 for typecheck logic, and continue the 
journey to next step: IR generation(directory: cmd/compile/internal/ir/).

It seems the ir package is a new abstract layer created during the refactor 
process of types2, and it's main purpose is to translate the AST to IR 
Tree. Before jumping into the code details, I would like to ask for some 
help from the community for the following questions:

1. In current typechecker(cmd/compile/internal/typecheck), the ir.Node tree 
is built along with the process of typecheck, those two processes are mixed 
with each other. Why and what's the design thoughts of creating a new layer 
named ir?

2. Currently package ir involves a lot of code of package 
types(cmd/compile/internal/types/) and package 
noder(cmd/compile/internal/noder/), which is used by the current 
typechecker(cmd/compile/internal/typecheck). If the Go team will replace 
types with types2 and abandon the current typechecker in the future, can I 
understand this "mixed-up style code" as a transitional stage to connect 
types2 to current typechecker for now? And there will be big changes for 
this part? If so, what's the plan?

3. If I want to write an article about IR generation, what's the best 
summary of topics for this phase? What I summarized now are: 
1). Translate AST to IR Tree;  
2). Analysis stack/heap usage for variables;
3). Handle generic instantiations;
   
 Are there other important topics/purposes I'm missing?
 
If I have any understanding errors, please help me to point them out; and 
if there's anything import you think I'm missing, or you think it's helpful 
to me, please tell me as well. 

Thanks for any help and tips.
On Monday, March 1, 2021 at 2:40:25 AM UTC+8 Ian Lance Taylor wrote:

> On Sun, Feb 28, 2021 at 7:04 AM zhz shi  wrote:
> >
> > According Russ's plan(replacing cmd/compile/internal/types with types2) 
> and the discussion topic Jeremy Faller posted, can I understand it as that 
> check2 will be the entry of new and default typechecker in the future(with 
> the release of 1.18 one year later)? And the current type-checking code 
> will be removed at the same time? If so I think I'd better to use master 
> branch for learning.
>
> That is likely but not certain.
>
>
> > And one more question please. I found there's copy of lex/parser and AST 
> dcls under https://github.com/golang/go/tree/master/src/go as public API, 
> why the compiler doesn't reuse this part of code, but keep a separate copy?
>
> The go/parser and related packages fall under the Go 1 compatibility
> guarantee, which makes it hard to update them as we learn more about
> what the compiler needs. Although there is duplicate code, it seems
> simpler overall for the compiler to have its own parser.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fb0efef8-162c-4dcf-bc69-c91724a475a0n%40googlegroups.com.

[go-nuts] Go compiler typechecker - why are there two ways to test type equality(checker.identical0() and unifier)?

[messi...@gmail.com]

Hi,

While reading the source code of typechecker, I found there're two ways to 
check type equality:
1. Method checker.identical(x, y Type) bool {}, defined in predicates.go, 
used by many places to see if two types are identical during typecheck 
process;
2. Method unifier.unify(x, y Type) bool {}, defined in unify.go,  used by 
method lookup to compare two Signature types

And there's comment "For changes to this code the corresponding changes 
should be made to unifier.nify." for method checker.identical0().

I wonder why there're two implementations for one thing? And if there're 
some reason, why the name "unify"?

Thanks for any help:-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e8f68b5c-44a5-4d74-a563-1f7456cc04e2n%40googlegroups.com.

Re: [go-nuts] go cycle reference type - what's the practical usage of decls like "type T *T" and similars?

[messi...@gmail.com]

Thanks Ian, the state machine case reminds me of a video by Rob 
Pike: https://www.youtube.com/watch?v=HxaD_trXwRE , put the link here to 
help others who are interested :-)

On Tuesday, March 16, 2021 at 12:58:00 PM UTC+8 Ian Lance Taylor wrote:

> On Mon, Mar 15, 2021 at 9:23 PM messi...@gmail.com
>  wrote:
> >
> > In file cycles.src there're many type declarations to demo cycle 
> reference, some are invalid and some are valid, I can understand why 
> invalid ones are invalid, but for some of the valid ones, I cannot figure 
> out their usage scenarios, take some as examples:
> >
> > type T *T // Does nil the only value a type T variable/const can hold?
> >
> > or with bigger cycle:
> > type ( // The same with above T for all T1, T2 and T3?
> > T1 T2
> > T2 *T3
> > T3 T1
> > )
>
> I'm not aware of any practical use for this. However, in Go we try to
> aim for simplicity and orthogonality where possible, even if that
> permits writing code that is not particularly useful. Rather than
> write a special rule like "pointer types may not be a loop," we simply
> permit it to work and avoid having another rule in the language.
>
> There is an amusing use of this kind of type in
> https://golang.org/test/peano.go, but it's not intended to be
> practical or useful.
>
>
> > or function type decl like:
> >
> > F func(F) F
> >
> > I'm wondering whether type decls like this do have practical usage, or 
> just for grammar learning?
>
> Types like
>
> type F func() F
>
> on the other hand, are useful for state machines. The idea is that
> the current state of some operation is expressed in the form of a
> function, and every call to the state function returns a function that
> implements the next state. There is an example of this at
> https://golang.org/src/text/template/parse/lex.go#L105.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/1ed7651f-8288-4f08-b5ad-d909f7bb5f53n%40googlegroups.com.

[go-nuts] go cycle reference type - what's the practical usage of decls like "type T *T" and similars?

[messi...@gmail.com]

Hi,

In file cycles.src 

 there're 
many type declarations to demo cycle reference, some are invalid and some 
are valid, I can understand why invalid ones are invalid, but for some of 
the valid ones, I cannot figure out their usage scenarios, take some as 
examples:

type T *T // Does nil the only value a type T variable/const can hold?

or with bigger cycle:
type ( // The same with above T for all T1, T2 and T3?
T1 T2
T2 *T3
T3 T1
)

or function type decl like:

F func(F) F

I'm wondering whether type decls like this do have practical usage, or  
just for grammar learning?

Thanks a lot.

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/2711edc7-e8d3-442f-b1ae-942daf134d71n%40googlegroups.com.

Re: [go-nuts] Re: Go compiler - where and how the implicit interface "comparable" used?

[messi...@gmail.com]

Thanks for your explanation, that's very helpful :-) 

On Friday, March 12, 2021 at 3:03:00 PM UTC+8 axel.wa...@googlemail.com 
wrote:

> On Fri, Mar 12, 2021 at 4:55 AM messi...@gmail.com  
> wrote:
>
>> Does it use for generics constraints only?
>
>
> That is my understanding.
>  
>
>> As described at 
>> https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#comparable-types-in-constraints
>>  
>> . If so the type comparison and this interface is two unrelated things?
>>
>
> They are related in the sense that `comparable` expresses exactly the 
> constraint of being able to compare values of a type. But the compiler 
> already knows how to compare values of the same type, if that type is 
> comparable. And the `comparable` interface won't be usable as an actual 
> type which can have a value (that would be useless - you need two values of 
> the same concrete type to actually compare, but there is, in general, no 
> guarantee that two values of an interface type are the same concrete type). 
> So there doesn't have to be a direct connection between the two.
>  
>
>>
>> On Friday, March 12, 2021 at 11:42:07 AM UTC+8 messi...@gmail.com wrote:
>>
>>> Hi, 
>>>
>>> I'm reading the new typechecker source code of go compiler(under 
>>> directory cmd/compile/internal/types2), during the initialization process, 
>>> universe.go registers an implicit interface "comparable" inside function 
>>> defPredeclaredComparable 
>>> <https://github.com/golang/go/blob/e8b82789cda6c9d9e3dfc9a652b4d7a823b834f2/src/cmd/compile/internal/types2/universe.go#L199>,
>>>  
>>> I know it's supposed to be used for type comparison 
>>> <https://golang.org/ref/spec#Comparison_operators>but failed to find 
>>> where and how this interface and related method "==" is used. 
>>>
>>> In predicates.go 
>>> <https://github.com/golang/go/blob/e8b82789cda6c9d9e3dfc9a652b4d7a823b834f2/src/cmd/compile/internal/types2/predicates.go#L86>
>>>  there's 
>>> a function 'Comparable" to check whether a type is comparable or not, but 
>>> seems there's nothing to do with the interface.
>>>
>>> And I don't understand the lookup logic for method "==" in type.go 
>>> <https://github.com/golang/go/blob/e8b82789cda6c9d9e3dfc9a652b4d7a823b834f2/src/cmd/compile/internal/types2/type.go#L465>
>>>  neither, 
>>> how could an Interface type have method named "=="?
>>>
>>> I searched a lot from the code base but failed to find the answer, could 
>>> anybody kindly give me some clue?
>>>
>>> Thanks a lot :-)
>>>
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "golang-nuts" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to golang-nuts...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/golang-nuts/50661f0e-289e-43f3-a9d7-a42feb77f7fbn%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/golang-nuts/50661f0e-289e-43f3-a9d7-a42feb77f7fbn%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/14cc2521-a155-48db-b000-a5300c6711f1n%40googlegroups.com.

[go-nuts] Re: Go compiler - where and how the implicit interface "comparable" used?

[messi...@gmail.com]

Does it use for generics constraints only? As described at 
https://go.googlesource.com/proposal/+/refs/heads/master/design/go2draft-type-parameters.md#comparable-types-in-constraints
 
. If so the type comparison and this interface is two unrelated things?

On Friday, March 12, 2021 at 11:42:07 AM UTC+8 messi...@gmail.com wrote:

> Hi, 
>
> I'm reading the new typechecker source code of go compiler(under directory 
> cmd/compile/internal/types2), during the initialization process, 
> universe.go registers an implicit interface "comparable" inside function 
> defPredeclaredComparable 
> <https://github.com/golang/go/blob/e8b82789cda6c9d9e3dfc9a652b4d7a823b834f2/src/cmd/compile/internal/types2/universe.go#L199>,
>  
> I know it's supposed to be used for type comparison 
> <https://golang.org/ref/spec#Comparison_operators>but failed to find 
> where and how this interface and related method "==" is used. 
>
> In predicates.go 
> <https://github.com/golang/go/blob/e8b82789cda6c9d9e3dfc9a652b4d7a823b834f2/src/cmd/compile/internal/types2/predicates.go#L86>
>  there's 
> a function 'Comparable" to check whether a type is comparable or not, but 
> seems there's nothing to do with the interface.
>
> And I don't understand the lookup logic for method "==" in type.go 
> <https://github.com/golang/go/blob/e8b82789cda6c9d9e3dfc9a652b4d7a823b834f2/src/cmd/compile/internal/types2/type.go#L465>
>  neither, 
> how could an Interface type have method named "=="?
>
> I searched a lot from the code base but failed to find the answer, could 
> anybody kindly give me some clue?
>
> Thanks a lot :-)
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/50661f0e-289e-43f3-a9d7-a42feb77f7fbn%40googlegroups.com.

[go-nuts] Go compiler - where and how the implicit interface "comparable" used?

[messi...@gmail.com]

Hi, 

I'm reading the new typechecker source code of go compiler(under directory 
cmd/compile/internal/types2), during the initialization process, 
universe.go registers an implicit interface "comparable" inside function 
defPredeclaredComparable 
,
 
I know it's supposed to be used for type comparison 
but failed to find where 
and how this interface and related method "==" is used. 

In predicates.go 

 there's 
a function 'Comparable" to check whether a type is comparable or not, but 
seems there's nothing to do with the interface.

And I don't understand the lookup logic for method "==" in type.go 

 neither, 
how could an Interface type have method named "=="?

I searched a lot from the code base but failed to find the answer, could 
anybody kindly give me some clue?

Thanks a lot :-)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/6a58f1e4-4f52-4a48-8a64-68b5a92c8d35n%40googlegroups.com.

Re: [go-nuts] Need help/tips on golang compiler souce code reading

[messi...@gmail.com]

Thanks for your suggestion, that's a good idea. Any specific ideas about 
how to do it? After all, the code/design is evolving all the time. 

On Friday, February 26, 2021 at 8:43:07 AM UTC+8 skinne...@gmail.com wrote:

> Ian, I very much appreciate your taking the time to provide the history 
> here.
> I am almost inclined to suggest that the OP create a design document much 
> the way an engineer creates an as-built design before creating a new design.
> For my part, I would be willing to assist the OP on an occasional basis in 
> trying to figure some things out just because I enjoy puzzles and I think 
> that these efforts to learn will pay great dividends in the future.
>
> On Thursday, February 25, 2021 at 8:56:01 AM UTC-6 Ian Lance Taylor wrote:
>
>> On Wed, Feb 24, 2021 at 10:24 PM messi...@gmail.com
>>  wrote:
>> >
>> > I'm trying to read golang compiler source code and now have come to the 
>> middle of syntax analysis: just finished parser.fileOrNil, next step is 
>> noder.node().
>> >
>> > So far everything is fine, both lex and syntax tree parsing is easy to 
>> understand. But after that part, it feels more and more difficult, in order 
>> to make my learning process smoother, I think I need to ask some help/tips 
>> from the community.
>> >
>> > Currently I'm doing it this way:
>> > 1. Figure out the main phases and the role of each one.
>> > 2. For each phase, figure out related data structures firstly, like 
>> interfaces and structs
>> > 3. Read the source code of the phase, figure out the main logic
>> > 3. Guess, and use UT to verify
>> > 4. Use git log to see the author's original thoughts
>> >
>> > Problems I'm facing:
>> > 1. Can't find enough docs, especially official design docs
>> > 2. Comment is not enough in code repo, I believe it's enough for 
>> compiler developers, but not for beginners like me
>> >
>> > This makes it very difficult to understand the design thoughts, in some 
>> cases you have to read the source code line by line for its purpose, but 
>> still don't know why it's implemented like that in the end.
>> >
>> > So my questions are:
>> > 1. Is there a place I can find the design docs for go compiler design?
>> > 2. What's the most productive way to learn the source code? Especially 
>> from the perspective of go compiler developers.
>> >
>> > Thanks for any helps/suggestions/tips :)
>>
>>
>> Unfortunately there are no design docs.
>>
>> The most productive approach is the one you are already doing. Feel
>> free to ask questions on this mailing list about why things are
>> written the way they are.
>>
>> That said, the history of the compiler is that it was originally
>> written in C and based on the Inferno C compiler. Ken Thompson
>> modified that compiler to compile Go code, but the compiler was itself
>> still written in C. Several years later Russ Cox wrote a tool to
>> translate the C code into Go code. That Go code was naturally not
>> very idiomatic. A lot of it has been rewritten, but some still looks
>> like C code. A couple of years after that Keith Randall rewrote the
>> entire backend to use an SSA representation. At some point Robert
>> Griesemer rewrote the entire parser. Matthew Dempsky and Russ Cox
>> rewrote a lot of the frontend. Right now Robert Griesemer and Rob
>> Findley are rewriting the type checker. Many other people have
>> written significant components of the compiler, replacing earlier
>> components.
>>
>> My point in providing this partial history is that many questions
>> about "why does the compiler work this way" have the answer "because
>> of the long and complicated history of the code base." It is not the
>> case that a group of people sat down and designed a clean and elegant
>> Go compiler. As far as I know nobody has ever written a Go compiler
>> from scratch.
>>
>> Ian
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/3e1f96e2-d933-4d35-9c8f-3cf6837e3daan%40googlegroups.com.

Re: [go-nuts] Need help/tips on golang compiler souce code reading

[messi...@gmail.com]

Thanks a lot for your time, Ian. The history info is very helpful.

I'm reading the source code of version 1.15.6, but I found the code base 
structure on master branch is very different, some changes are refactors as 
you mentioned above(typechecker), and some are for new features(e.g. 
generics). Contribution guide <https://golang.org/doc/contribute> says 
Github issue tracker is the place where contributors take task from, but 
most of the issues are about bugs, so how about the kind of "Features" and 
"Plans"? Take the typechecker-rewriting task you mentioned above as 
example,  I searched a lot to try to find the "kickoff" place and the 
original discussion but failed. (Most of issues assigned to Griesemer are 
specific bug or improvement.)

Is there any place/information I missed? Or reading the source code is the 
only way to fully catch up the whole process?

Thanks again. 

On Thursday, February 25, 2021 at 10:56:01 PM UTC+8 Ian Lance Taylor wrote:

> On Wed, Feb 24, 2021 at 10:24 PM messi...@gmail.com
>  wrote:
> >
> > I'm trying to read golang compiler source code and now have come to the 
> middle of syntax analysis: just finished parser.fileOrNil, next step is 
> noder.node().
> >
> > So far everything is fine, both lex and syntax tree parsing is easy to 
> understand. But after that part, it feels more and more difficult, in order 
> to make my learning process smoother, I think I need to ask some help/tips 
> from the community.
> >
> > Currently I'm doing it this way:
> > 1. Figure out the main phases and the role of each one.
> > 2. For each phase, figure out related data structures firstly, like 
> interfaces and structs
> > 3. Read the source code of the phase, figure out the main logic
> > 3. Guess, and use UT to verify
> > 4. Use git log to see the author's original thoughts
> >
> > Problems I'm facing:
> > 1. Can't find enough docs, especially official design docs
> > 2. Comment is not enough in code repo, I believe it's enough for 
> compiler developers, but not for beginners like me
> >
> > This makes it very difficult to understand the design thoughts, in some 
> cases you have to read the source code line by line for its purpose, but 
> still don't know why it's implemented like that in the end.
> >
> > So my questions are:
> > 1. Is there a place I can find the design docs for go compiler design?
> > 2. What's the most productive way to learn the source code? Especially 
> from the perspective of go compiler developers.
> >
> > Thanks for any helps/suggestions/tips :)
>
>
> Unfortunately there are no design docs.
>
> The most productive approach is the one you are already doing. Feel
> free to ask questions on this mailing list about why things are
> written the way they are.
>
> That said, the history of the compiler is that it was originally
> written in C and based on the Inferno C compiler. Ken Thompson
> modified that compiler to compile Go code, but the compiler was itself
> still written in C. Several years later Russ Cox wrote a tool to
> translate the C code into Go code. That Go code was naturally not
> very idiomatic. A lot of it has been rewritten, but some still looks
> like C code. A couple of years after that Keith Randall rewrote the
> entire backend to use an SSA representation. At some point Robert
> Griesemer rewrote the entire parser. Matthew Dempsky and Russ Cox
> rewrote a lot of the frontend. Right now Robert Griesemer and Rob
> Findley are rewriting the type checker. Many other people have
> written significant components of the compiler, replacing earlier
> components.
>
> My point in providing this partial history is that many questions
> about "why does the compiler work this way" have the answer "because
> of the long and complicated history of the code base." It is not the
> case that a group of people sat down and designed a clean and elegant
> Go compiler. As far as I know nobody has ever written a Go compiler
> from scratch.
>
> Ian
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/5e52abe8-bf12-4254-96c3-04861700a0fcn%40googlegroups.com.

[go-nuts] Need help/tips on golang compiler souce code reading

[messi...@gmail.com]

Hi,

I'm trying to read golang compiler source code and now have come to the 
middle of syntax analysis: just finished parser.fileOrNil 
,
 
next step is noder.node() 

.  

So far everything is fine,  both lex and syntax tree 

 parsing 
is easy to understand. But after that part, it feels more and more 
difficult, in order to make my learning process smoother, I think I need to 
ask some help/tips from the community.

Currently I'm doing it this way:
1. Figure out the main phases and the role of each one.  
2. For each phase, figure out related data structures firstly, like 
interfaces and structs
3. Read the source code of the phase, figure out the main logic
3. Guess, and use UT to verify
4. Use git log to see the author's original thoughts

Problems I'm facing: 
1. Can't find enough docs, especially official design docs
2. Comment is not enough in code repo, I believe it's enough for compiler 
developers, but not for beginners like me

This makes it very difficult to understand the design thoughts, in some 
cases you have to read the source code line by line for its purpose, but 
still don't know why it's implemented like that in the end.

So my questions are:
1. Is there a place I can find the design docs for go compiler design?
2. What's the most productive way to learn the source code? Especially from 
the perspective of go compiler developers. 

Thanks for any helps/suggestions/tips :)

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/0ef2340e-15b6-4ed2-81d2-03ddfed3f302n%40googlegroups.com.

[go-nuts] Re: Code style in golang compiler

[messi...@gmail.com]

Thanks, the commit message explains everything :-)

On Tuesday, February 9, 2021 at 11:51:16 AM UTC+8 Luke Champine wrote:

> git blame is instructive here. The commit in question is: 
> https://github.com/golang/go/commit/166b1219b8a5b246c83986c7ecef3d15c85c8150
>
> I can't claim to fully understand the commit message, but I believe that 
> this change will cause the runtime to allocate both values together, rather 
> than separately, and this slightly reduces GC pressure.
>
> On Monday, February 8, 2021 at 10:37:29 PM UTC-5 messi...@gmail.com wrote:
>
>> Hi,
>>
>> I'm reading the go compiler source code and found the following code 
>> style in several places:
>>
>> [image: DeepinScreenshot_select-area_20210209105635.png]
>>
>> Is there some special reasons to group n,m,p to a local struct? 
>>
>> Why don't we just init n the following way:
>>
>> [image: DeepinScreenshot_select-area_20210209110823.png]
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/e6522f8e-9bd5-4e88-803f-293c41771e3bn%40googlegroups.com.

[go-nuts] Code style in golang compiler

[messi...@gmail.com]

Hi,

I'm reading the go compiler source code and found the following code style 
in several places:

[image: DeepinScreenshot_select-area_20210209105635.png]

Is there some special reasons to group n,m,p to a local struct? 

Why don't we just init n the following way:

[image: DeepinScreenshot_select-area_20210209110823.png]

-- 
You received this message because you are subscribed to the Google Groups 
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/golang-nuts/fcd440cd-9959-4230-8d22-06495d51695dn%40googlegroups.com.