FAQ
A few weeks ago I sent out a doc about refactoring the linker, moving as
much as possible into the compilers and rewriting what remains of the
linker in Go. The refactoring is done, surely with some corner case bugs
introduced, and it has already made the linker faster. The new linker in Go
is in progress (very early, no CLs yet). That plan is at
golang.org/s/go13linker.

Once the linker is done, we intend to move the Go compiler itself. But
instead of converting it by hand we intend to use a new mechanical
translator to do the bulk of the work and then use new mechanical
refactoring tools to help turn the resulting monolithic package main into a
more idiomatic Go program built from packages.

golang.org/s/go13compiler has details. Comments welcome here.

Russ

--

---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Dave Cheney at Dec 18, 2013 at 10:28 pm
    LGTM, would read again.

    Do you plan to also expose the Go in Go compiler as a package so it could be called directly from cmd/go or embedded in other build tools?
    On 19 Dec 2013, at 9:11, Russ Cox wrote:

    A few weeks ago I sent out a doc about refactoring the linker, moving as much as possible into the compilers and rewriting what remains of the linker in Go. The refactoring is done, surely with some corner case bugs introduced, and it has already made the linker faster. The new linker in Go is in progress (very early, no CLs yet). That plan is at golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But instead of converting it by hand we intend to use a new mechanical translator to do the bulk of the work and then use new mechanical refactoring tools to help turn the resulting monolithic package main into a more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.

    Russ
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Josh Bleecher Snyder at Dec 18, 2013 at 10:46 pm
    Exciting!

    Is the translator likely to live on as an independent project, for
    others with C to Go porting projects?

    -josh

    On Wed, Dec 18, 2013 at 2:28 PM, Dave Cheney wrote:
    LGTM, would read again.

    Do you plan to also expose the Go in Go compiler as a package so it could be
    called directly from cmd/go or embedded in other build tools?

    On 19 Dec 2013, at 9:11, Russ Cox wrote:

    A few weeks ago I sent out a doc about refactoring the linker, moving as
    much as possible into the compilers and rewriting what remains of the linker
    in Go. The refactoring is done, surely with some corner case bugs
    introduced, and it has already made the linker faster. The new linker in Go
    is in progress (very early, no CLs yet). That plan is at
    golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But
    instead of converting it by hand we intend to use a new mechanical
    translator to do the bulk of the work and then use new mechanical
    refactoring tools to help turn the resulting monolithic package main into a
    more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.

    Russ

    --

    ---
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

    --

    ---
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Dec 18, 2013 at 10:58 pm

    On Wed, Dec 18, 2013 at 5:46 PM, Josh Bleecher Snyder wrote:

    Exciting!
    yeah! the plan is so clear that i cannot find anything to comment on first
    read.
    Is the translator likely to live on as an independent project, for
    others with C to Go porting projects?
    i have the same question as I've already come up with a target: sqlite.
    unfortunately, it does use unions.

    I'm also pretty excited that there might be C backend for Go again because
    I always wanted to use (simplified) Go in my embedded projects (which don't
    use an OS at all or uses RTOS like VxWorks [although gccgo seems to
    support RTEMS, but I didn't have chance to use RTEMS yet])

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Dec 18, 2013 at 11:54 pm

    On Wed, Dec 18, 2013 at 5:46 PM, Josh Bleecher Snyder wrote:

    Exciting!

    Is the translator likely to live on as an independent project, for
    others with C to Go porting projects?
    The translator will be published. I suspect it will have a fair number of
    rules specific to our style of C and our code base. I don't know how
    applicable it will be to other code bases, but if others want to run with
    it, it will be there to try.

    Russ

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Mikey at Dec 11, 2014 at 3:30 pm
    Has the translator been published yet? If so, where can it be found?
    On Wednesday, December 18, 2013 6:54:37 PM UTC-5, rsc wrote:

    On Wed, Dec 18, 2013 at 5:46 PM, Josh Bleecher Snyder <josh...@gmail.com
    <javascript:>> wrote:
    Is the translator likely to live on as an independent project, for
    others with C to Go porting projects?
    The translator will be published. I suspect it will have a fair number of
    rules specific to our style of C and our code base. I don't know how
    applicable it will be to other code bases, but if others want to run with
    it, it will be there to try.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Russ Cox at Dec 11, 2014 at 3:39 pm
    no.
    On Thu, Dec 11, 2014 at 9:03 AM, Mikey wrote:

    Has the translator been published yet? If so, where can it be found?
    On Wednesday, December 18, 2013 6:54:37 PM UTC-5, rsc wrote:

    On Wed, Dec 18, 2013 at 5:46 PM, Josh Bleecher Snyder <josh...@gmail.com>
    wrote:
    Is the translator likely to live on as an independent project, for
    others with C to Go porting projects?
    The translator will be published. I suspect it will have a fair number of
    rules specific to our style of C and our code base. I don't know how
    applicable it will be to other code bases, but if others want to run with
    it, it will be there to try.
    --
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • James4k at Dec 18, 2013 at 11:44 pm
    In some ways this is exciting, but not so much in regards to bootstrapping.

    From the FAQ:
    "We considered writing gc, the original Go compiler, in Go itself but
    elected not to do so because of the difficulties of bootstrapping and
    especially of open source distribution—you'd need a Go compiler to set up a
    Go environment..." [1]

    It goes on to consider gccgo to build a Go compiler, but here the decision
    seems to be to bootstrap.

    You also argued against the decision to bootstrap in your "A Tour of Go"
    talk. Fun quote at the end of your argument: "When we were planning the
    initial open source release, we liked to joke that no one in their right
    mind would accept a bootstrapped compiler binary written by Ken." [2]

    So, I am curious what has changed with this decision to start bootstrapping.

    Thanks

    [1] http://golang.org/doc/faq
    [2] http://research.swtch.com/gotour
    On Wednesday, December 18, 2013 4:11:07 PM UTC-6, rsc wrote:

    A few weeks ago I sent out a doc about refactoring the linker, moving as
    much as possible into the compilers and rewriting what remains of the
    linker in Go. The refactoring is done, surely with some corner case bugs
    introduced, and it has already made the linker faster. The new linker in Go
    is in progress (very early, no CLs yet). That plan is at
    golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But
    instead of converting it by hand we intend to use a new mechanical
    translator to do the bulk of the work and then use new mechanical
    refactoring tools to help turn the resulting monolithic package main into a
    more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.

    Russ
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Dec 18, 2013 at 11:53 pm

    On Wed, Dec 18, 2013 at 6:44 PM, james4k wrote:

    In some ways this is exciting, but not so much in regards to bootstrapping.

    From the FAQ:
    "We considered writing gc, the original Go compiler, in Go itself but
    elected not to do so because of the difficulties of bootstrapping and
    especially of open source distribution—you'd need a Go compiler to set up a
    Go environment..." [1]

    It goes on to consider gccgo to build a Go compiler, but here the decision
    seems to be to bootstrap.

    You also argued against the decision to bootstrap in your "A Tour of Go"
    talk. Fun quote at the end of your argument: "When we were planning the
    initial open source release, we liked to joke that no one in their right
    mind would accept a bootstrapped compiler binary written by Ken." [2]
    The important part of the answer in my talk (aside from the joke about Ken)
    is:

    I’ve worked on bootstrapped languages in the past, and *I found that
    bootstrapping is not necessarily a good fit for languages that are changing
    frequently*. It reminded me of climbing a cliff and screwing hooks into the
    cliff once in a while to catch you if you fall. Once or twice I got into
    situations where I had identified a bug in the compiler, but then trying to
    write the code to fix the bug tickled the bug, so it couldn’t be compiled.
    And then you have to think hard about how to write the fix in a way that
    avoids the bug, or else go back through your version control history to
    find a way to replay history without introducing the bug. It’s not fun.

    The fact that Go wasn’t written in itself also made it much easier to make
    significant language changes. Before the initial release we went through a
    handful of wholesale syntax upheavals, and I’m glad we didn’t have to worry
    about how we were going to rebootstrap the compiler or ensure some kind of
    backwards compatibility during those changes.

    [Emphasis added.]


    The main thing that has changed compared to 2008 is that Go is not changing
    frequently. In fact it is very stable. The kinds of problems I outline in
    that answer are not concerns anymore. The maintenance burdens of working in
    C is a much bigger problem.

    As for exactly how to build the compilers from scratch, the exact details
    don't really matter as long as there is at least one viable plan (and I
    think there are three). We could use gccgo, we could use a preinstalled
    binary Go compiler on, say, Linux distributions with binary Go packages, or
    we could build a sequence of compilers from the Mercurial repo. I think
    running two or three make.bash instances will be faster than building gccgo
    once (such is gcc), but really any approach that builds the compiler is
    fine.

    Russ

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brainman at Apr 1, 2014 at 10:52 pm
    I read this
    http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler.html yesterday.
    But maybe it is one of those "April the 1st" jokes. :-)

    Alex

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Lucio De Re at Apr 2, 2014 at 4:28 am
    If it is a joke, it is a rather elaborate one and, in my initial
    reading as an old hand, a very instructive one. I do wish I could use
    such an approach to teach about computers, rather than start as
    literacy courses do around here.

    Which of course I now feel inspired to do: I have enough embedded
    hardware to do so. The target audience may be more complicated.

    Thanks, Alex, for pointing me to it. The journey to Go may be long,
    starting here, but it sounds like fun all the way :-)

    Lucio.

    On 4/2/14, brainman wrote:
    I read this
    http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler.html yesterday.

    But maybe it is one of those "April the 1st" jokes. :-)

    Alex

    --

    ---
    You received this message because you are subscribed to the Google Groups
    "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Aram Hăvărneanu at Apr 2, 2014 at 7:39 am
    Why would it be a joke? The source code is here:
    http://homepage.ntlworld.com/edmund.grimley-evans/bcompiler.tar.gz

    --
    Aram Hăvărneanu

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Andrew Wilkins at Dec 19, 2013 at 2:22 am

    On Thursday, 19 December 2013 06:11:07 UTC+8, rsc wrote:
    A few weeks ago I sent out a doc about refactoring the linker, moving as
    much as possible into the compilers and rewriting what remains of the
    linker in Go. The refactoring is done, surely with some corner case bugs
    introduced, and it has already made the linker faster. The new linker in Go
    is in progress (very early, no CLs yet). That plan is at
    golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But
    instead of converting it by hand we intend to use a new mechanical
    translator to do the bulk of the work and then use new mechanical
    refactoring tools to help turn the resulting monolithic package main into a
    more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.

    Russ
    This is very exciting. I'd like to get involved at some point.

    You wrote, "It may be based on SSA and if so would certainly take advantage
    of the lessons learned from Alan Donovan’s go.tools/ssa package"; is there
    a possibility of just using go.tools/ssa? This is what I am in the progress
    of doing with llgo.

    It would be of great interest to me to have the runtime rewritten in Go,
    for ease of reuse. I was intending to use libgo, but I think this would be
    a better solution.

    Cheers,
    Andrew

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Dec 19, 2013 at 2:53 am

    On Dec 18, 2013 9:22 PM, "Andrew Wilkins" wrote:
    It would be of great interest to me to have the runtime rewritten in Go,
    for ease of reuse. I was intending to use libgo, but I think this would be
    a better solution.
    i wonder why can't we start migrating runtime to Go now? I think Dave
    Cheney proposed that we wrote runtime in Go, one piece at a time, very long
    time ago.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brad Fitzpatrick at Dec 19, 2013 at 2:57 am
    On Wed, Dec 18, 2013 at 6:53 PM, minux wrote:
    On Dec 18, 2013 9:22 PM, "Andrew Wilkins" wrote:
    It would be of great interest to me to have the runtime rewritten in Go,
    for ease of reuse. I was intending to use libgo, but I think this would be
    a better solution.
    i wonder why can't we start migrating runtime to Go now? I think Dave
    Cheney proposed that we wrote runtime in Go, one piece at a time, very long
    time ago.

    I don't think anybody really objects. Which piece would you start with?

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Andrew Wilkins at Dec 19, 2013 at 3:07 am

    On 19 December 2013 10:57, Brad Fitzpatrick wrote:
    On Wed, Dec 18, 2013 at 6:53 PM, minux wrote:

    On Dec 18, 2013 9:22 PM, "Andrew Wilkins" wrote:
    It would be of great interest to me to have the runtime rewritten in
    Go, for ease of reuse. I was intending to use libgo, but I think this would
    be a better solution.
    i wonder why can't we start migrating runtime to Go now? I think Dave
    Cheney proposed that we wrote runtime in Go, one piece at a time, very long
    time ago.
    If that's the case, I'd be happy to help. I don't want to sidetrack this
    discussion too much though, perhaps another thread is in order.

    I don't think anybody really objects. Which piece would you start with?
    >

    Not sure where I'd start (probably with the basics like rune.c, complex.c,
    ...), but I wonder if it'd be worth having some safeguards in place first.
    Namely, a mode for the compiler to reject escaping vars for code that
    should not be exercising the GC.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David Symonds at Dec 19, 2013 at 3:25 am
    Except it might be nice to not radically change so much stuff at once.
    Go 1.3 is going to be rewriting the linker, maybe the compiler, and
    there will probably be GC changes. One could reasonably worry about
    making it hard to keep things correct if there's too much stuff
    churning at the same time.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Pike at Dec 19, 2013 at 3:42 am
    I support what dsymonds@ just said. We're rewriting lots of stuff
    already and it's just the start of a long-term plan. While it's
    happening, everything has to stay working and, at last at known
    milestones, compatibly with existing code.

    We shouldn't start ripping everything apart right away.

    -rob

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dave Cheney at Dec 19, 2013 at 3:52 am
    I agree, let's leave something left to do next year.
    On 19 Dec 2013, at 14:42, Rob Pike wrote:

    I support what dsymonds@ just said. We're rewriting lots of stuff
    already and it's just the start of a long-term plan. While it's
    happening, everything has to stay working and, at last at known
    milestones, compatibly with existing code.

    We shouldn't start ripping everything apart right away.

    -rob

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Hans Stimer at Dec 19, 2013 at 6:05 am
    Runtime in Go?

    I'm certainly not opposed to Go in Go, but runtime in Go concerns me. The
    runtime, which still has serious performance issues for certain use cases,
    is heavily optimized and I can't see how writing it in Go will make that
    code any easier to write, understand, or faster.

    Is the Go compiler going to get a much better optimizer? What language
    extensions will be required? Or, are those speed critical pieces going to
    be rewritten in assembly?
    On Wednesday, December 18, 2013 2:11:07 PM UTC-8, rsc wrote:

    A few weeks ago I sent out a doc about refactoring the linker, moving as
    much as possible into the compilers and rewriting what remains of the
    linker in Go. The refactoring is done, surely with some corner case bugs
    introduced, and it has already made the linker faster. The new linker in Go
    is in progress (very early, no CLs yet). That plan is at
    golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But
    instead of converting it by hand we intend to use a new mechanical
    translator to do the bulk of the work and then use new mechanical
    refactoring tools to help turn the resulting monolithic package main into a
    more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.

    Russ
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Dec 19, 2013 at 6:26 am

    On Thu, Dec 19, 2013 at 1:05 AM, wrote:

    Runtime in Go?

    I'm certainly not opposed to Go in Go, but runtime in Go concerns me. The
    runtime, which still has serious performance issues for certain use cases,
    is heavily optimized and I can't see how writing it in Go will make that
    code any easier to write, understand, or faster.
    I can't comment on whether the C version is heavily optimized. But I can
    definitely say that Go is
    easier to write and understand than C, and very probably also faster.

    Besides, Go was intended to be system programming language when first
    designed, if it couldn't
    write its own runtime, how could it be called a "system" programming
    language.
    (I understand that part of the runtime must be written in assembler, that's
    unavoidable,
    and I'm talking about the higher level things, like string/map/scheduler,
    or even the GC)
    Is the Go compiler going to get a much better optimizer? What language
    extensions will be required? Or, are those speed critical pieces going to
    be rewritten in assembly?
    The Go compiler (in gc toolchain) is already much better than the C
    compiler, for example, the C compiler
    couldn't do any inlining, so we resort to macros for some performance
    gains. If we rewrite in Go, some
    macros will go away while retaining the benefits.

    Try comparing the generated code from 6g and 6c yourself.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Hudson-Doyle at Dec 19, 2013 at 9:02 pm

    Russ Cox writes:

    A few weeks ago I sent out a doc about refactoring the linker, moving as
    much as possible into the compilers and rewriting what remains of the
    linker in Go. The refactoring is done, surely with some corner case bugs
    introduced, and it has already made the linker faster. The new linker in Go
    is in progress (very early, no CLs yet). That plan is at
    golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But
    instead of converting it by hand we intend to use a new mechanical
    translator to do the bulk of the work and then use new mechanical
    refactoring tools to help turn the resulting monolithic package main into a
    more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.
    This is just a tangent I guess, but as someone who might be working on
    porting the gc toolchain to a new architecture in the 1.4/1.5 timeframe,
    it seems to me that these changes make the existence or otherwise of a
    plan9/inferno toolchain for an architecture much less relevant to doing
    a go toolchain port. Does that seem a reasonable interpretation?

    This isn't meant to sound whiny, btw, I'd much rather implement arm64
    support in Go I think...

    Cheers,
    mwh

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Dec 19, 2013 at 9:43 pm

    On Thu, Dec 19, 2013 at 4:02 PM, Michael Hudson-Doyle wrote:

    Russ Cox <rsc@golang.org> writes:
    A few weeks ago I sent out a doc about refactoring the linker, moving as
    much as possible into the compilers and rewriting what remains of the
    linker in Go. The refactoring is done, surely with some corner case bugs
    introduced, and it has already made the linker faster. The new linker in Go
    is in progress (very early, no CLs yet). That plan is at
    golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But
    instead of converting it by hand we intend to use a new mechanical
    translator to do the bulk of the work and then use new mechanical
    refactoring tools to help turn the resulting monolithic package main into a
    more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.
    This is just a tangent I guess, but as someone who might be working on
    porting the gc toolchain to a new architecture in the 1.4/1.5 timeframe,
    it seems to me that these changes make the existence or otherwise of a
    plan9/inferno toolchain for an architecture much less relevant to doing
    a go toolchain port. Does that seem a reasonable interpretation?
    I don't believe that's true. It's the same toolchain, just with pieces
    written in Go instead of C. We could incorporate the arm64 bits by applying
    the translator - the same process for incorporating the current 386, amd64,
    and arm bits. I think it would be a mistake to try to start from scratch
    instead unless you were very familiar with the code and the arm64.

    It's never been the case that you could just cp the Inferno compiler
    sources into the Go tree, and it is true that we're making the gap between
    the two trees wider.

    Russ

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Michael Hudson-Doyle at Dec 20, 2013 at 12:27 am

    Russ Cox writes:

    On Thu, Dec 19, 2013 at 4:02 PM, Michael Hudson-Doyle <
    michael.hudson@linaro.org> wrote:
    Russ Cox <rsc@golang.org> writes:
    A few weeks ago I sent out a doc about refactoring the linker, moving as
    much as possible into the compilers and rewriting what remains of the
    linker in Go. The refactoring is done, surely with some corner case bugs
    introduced, and it has already made the linker faster. The new linker in Go
    is in progress (very early, no CLs yet). That plan is at
    golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But
    instead of converting it by hand we intend to use a new mechanical
    translator to do the bulk of the work and then use new mechanical
    refactoring tools to help turn the resulting monolithic package main into a
    more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.
    This is just a tangent I guess, but as someone who might be working on
    porting the gc toolchain to a new architecture in the 1.4/1.5 timeframe,
    it seems to me that these changes make the existence or otherwise of a
    plan9/inferno toolchain for an architecture much less relevant to doing
    a go toolchain port. Does that seem a reasonable interpretation?
    I don't believe that's true. It's the same toolchain, just with pieces
    written in Go instead of C. We could incorporate the arm64 bits by applying
    the translator - the same process for incorporating the current 386, amd64,
    and arm bits. I think it would be a mistake to try to start from scratch
    instead unless you were very familiar with the code and the arm64. OK.
    It's never been the case that you could just cp the Inferno compiler
    sources into the Go tree, and it is true that we're making the gap between
    the two trees wider.
    Fair enough.

    Cheers,
    mwh

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Daniel Morsing at Dec 20, 2013 at 4:56 pm

    On Wed, Dec 18, 2013 at 11:11 PM, Russ Cox wrote:
    A few weeks ago I sent out a doc about refactoring the linker, moving as much as possible into the compilers and rewriting what remains of the linker in Go. The refactoring is done, surely with some corner case bugs introduced, and it has already made the linker faster. The new linker in Go is in progress (very early, no CLs yet). That plan is at golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But instead of converting it by hand we intend to use a new mechanical translator to do the bulk of the work and then use new mechanical refactoring tools to help turn the resulting monolithic package main into a more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.

    Russ
    Something I'm wondering about is how you manage the translation of
    go.y. Translating the C output would make the parser source code read
    only and I don't know if the in-tree yacc has all the features that we
    use in that file. I'm particularly wondering about mid rule actions.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Dec 20, 2013 at 4:59 pm

    On Fri, Dec 20, 2013 at 11:56 AM, Daniel Morsing wrote:

    Something I'm wondering about is how you manage the translation of
    go.y. Translating the C output would make the parser source code read
    only and I don't know if the in-tree yacc has all the features that we
    use in that file. I'm particularly wondering about mid rule actions.
    It will require a little cleverness. Probably translate the .tab.c file and
    then extract the action bodies back into a Go .y file.

    mid-rule actions are standard. I am using one or two bison-specific
    extensions but we can update go tool yacc as needed.

    Russ

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Dawes at Dec 21, 2013 at 4:39 pm
    Any chance we can get some more information on the new mechanical
    refactoring tools? Serious refactoring tools is the only thing I miss from
    my Java development environment.

         Ian.
    On Wednesday, 18 December 2013 17:11:07 UTC-5, rsc wrote:

    A few weeks ago I sent out a doc about refactoring the linker, moving as
    much as possible into the compilers and rewriting what remains of the
    linker in Go. The refactoring is done, surely with some corner case bugs
    introduced, and it has already made the linker faster. The new linker in Go
    is in progress (very early, no CLs yet). That plan is at
    golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. But
    instead of converting it by hand we intend to use a new mechanical
    translator to do the bulk of the work and then use new mechanical
    refactoring tools to help turn the resulting monolithic package main into a
    more idiomatic Go program built from packages.

    golang.org/s/go13compiler has details. Comments welcome here.

    Russ
    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Benny Siegert at Dec 29, 2013 at 4:50 pm
    Putting on my packager hat, I have a comment about the proposed bootstrap
    process. Frankly, I am slightly worried.

    In pkgsrc, we currently have a big problem with ghc, the Haskell compiler.
    To bootstrap it, you need an older ghc binary for the same platform, and to
    bootstrap that, a binary of an even older version, which had been in C.
    This is a huge pain to do, and it is hurting that package in pkgsrc.

    The bootstrap process you propose is essentially the same, but automated. I
    hope that along with the script, there will be a tarball somewhere with all
    the required sources, so that you can do this as part of a package build
    from scratch.

    But what happens if you add some other architecture in the meantime? Does
    that mean that, say, a hypothetical netbsd-arm64 port written _after_ the
    switch to would not have the C-based bootstrap available?

    Also, what if there is some change required for a newer OS version (e.g. in
    the syscall package)? Does that mean that these changes then need to be
    backported to all the older versions in that bootstrap chain?

    --Benny.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Dec 29, 2013 at 7:05 pm

    On Sun, Dec 29, 2013 at 8:50 AM, Benny Siegert wrote:
    The bootstrap process you propose is essentially the same, but automated. I
    hope that along with the script, there will be a tarball somewhere with all
    the required sources, so that you can do this as part of a package build
    from scratch.
    That seems doable. Want to work on it when the time comes?
    But what happens if you add some other architecture in the meantime? Does
    that mean that, say, a hypothetical netbsd-arm64 port written _after_ the
    switch to would not have the C-based bootstrap available?
    The first version would have to be built with a cross-compiler.
    Also, what if there is some change required for a newer OS version (e.g. in
    the syscall package)? Does that mean that these changes then need to be
    backported to all the older versions in that bootstrap chain?
    That seems like an unlikely scenario, as it implies that older
    binaries would not run on the newer OS. The Go syscall package of a
    Go release does not depend on any part of the build environment.

    These are real issues and they can't be ignored, but we know they are
    solvable in principle because the same issues arise for C compilers.
    It's only a question of making it sufficiently convenient.

    Ian

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rémy Oudompheng at Dec 29, 2013 at 7:30 pm

    On 2013/12/29 Benny Siegert wrote:
    Putting on my packager hat, I have a comment about the proposed bootstrap
    process. Frankly, I am slightly worried.

    In pkgsrc, we currently have a big problem with ghc, the Haskell compiler.
    To bootstrap it, you need an older ghc binary for the same platform, and to
    bootstrap that, a binary of an even older version, which had been in C. This
    is a huge pain to do, and it is hurting that package in pkgsrc.

    The bootstrap process you propose is essentially the same, but automated. I
    hope that along with the script, there will be a tarball somewhere with all
    the required sources, so that you can do this as part of a package build
    from scratch.

    But what happens if you add some other architecture in the meantime? Does
    that mean that, say, a hypothetical netbsd-arm64 port written _after_ the
    switch to would not have the C-based bootstrap available?

    Also, what if there is some change required for a newer OS version (e.g. in
    the syscall package)? Does that mean that these changes then need to be
    backported to all the older versions in that bootstrap chain?
    Are your worries still applicable if, for example, the bootstrap
    process can use gccgo? It seems to me that packaging gccgo is easy on
    many platforms.

    Regards,
    Rémy.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Dec 31, 2013 at 4:46 pm

    On Dec 29, 2013 2:30 PM, "Rémy Oudompheng" wrote:
    On 2013/12/29 Benny Siegert wrote:
    Putting on my packager hat, I have a comment about the proposed
    bootstrap
    process. Frankly, I am slightly worried.

    In pkgsrc, we currently have a big problem with ghc, the Haskell
    compiler.
    To bootstrap it, you need an older ghc binary for the same platform,
    and to
    bootstrap that, a binary of an even older version, which had been in C.
    This
    is a huge pain to do, and it is hurting that package in pkgsrc.

    The bootstrap process you propose is essentially the same, but
    automated. I
    hope that along with the script, there will be a tarball somewhere with
    all
    the required sources, so that you can do this as part of a package build
    from scratch.

    But what happens if you add some other architecture in the meantime?
    Does
    that mean that, say, a hypothetical netbsd-arm64 port written _after_
    the
    switch to would not have the C-based bootstrap available?

    Also, what if there is some change required for a newer OS version
    (e.g. in
    the syscall package)? Does that mean that these changes then need to be
    backported to all the older versions in that bootstrap chain?
    Are your worries still applicable if, for example, the bootstrap
    process can use gccgo? It seems to me that packaging gccgo is easy on
    many platforms.
    except that gccgo currently does not support any of *BSD, Darwin.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Jan 6, 2014 at 8:28 pm
    How do you manage to package gcc? Do you go back to a C compiler written in
    B?

    Russ

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Ian Lance Taylor at Jan 6, 2014 at 9:16 pm

    On Mon, Jan 6, 2014 at 12:28 PM, Russ Cox wrote:
    How do you manage to package gcc? Do you go back to a C compiler written in
    B?
    GNAT (the GNU Ada Translator) is an even better example, as it is
    written in Ada and alternative free Ada compilers are hard to find.

    Ian

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Brett Mahar at Dec 30, 2013 at 7:55 pm

    On Thursday, 19 December 2013 09:11:07 UTC+11, rsc wrote:
    A few weeks ago I sent out a doc about refactoring the linker, moving as
    much as possible into the compilers and rewriting what remains of the
    linker in Go. The refactoring is done, surely with some corner case bugs
    introduced, and it has already made the linker faster. The new linker in Go
    is in progress (very early, no CLs yet). That plan is at
    golang.org/s/go13linker.

    Once the linker is done, we intend to move the Go compiler itself. [...]
    I'm not much of a programmer but have been looking at Go recently and
    playing around with it, and am happy with its minimalism and
    understandability. When first looking at it, one of the things that made it
    attractive was the decision not to write the compiler in Go. Seeing the
    original post in this topic reminded me of what became of Haskell - see
    http://marc.info/?l=openbsd-ports&m=136796351325773&w=2 , and (later in the
    same email chain) this nightmarish scenario:

    "At the moment, I'm running a test-build of ghc-7.4 using ghc-7.0
    bootstrapped from ghc-6.12 bootstrapped from ghc-6.10 boostrapped
    from 6.6 bootstrapped from nothing but a (still machine and os
    dependent) .hc file bundle on amd64 running inside qemu on the
    desktop pc in my office (and -- whow -- it's crappy). If this
    succeeds, and if the whole process also works on i386 without too
    many additional fixes, the ghc port will survive at least until the
    flag day and until I start to work on an update to ghc-7.6.3 and
    haskell-platform-2013.2.0.0."

    The "flag day" referred to above was the switch from 32bit to 64bit time.
    It seems overly-optimistic to assume that no such "flag day" (which occur
    from time to time in OS developement) will stop a prior version of Go from
    running (and therefore allow it to be available) for building the newer
    version, notwithstanding that it is statically compiled or makes few system
    calls does not deviate from Go1.0 or whatver.

    If the switch to Go written in Go is to happen, it seems the way least
    likely to destroy it over time is to bootstrap using gccgo rather than Go -
    and also allow bootstrapping from llvm-go (if/when it comes along). In this
    way the entire language would not be able to be held hostage by gcc
    developers classifying a bug or two as "not to be fixed."

    To end on a positive note, Go so far to me looks very good and after 3 or 4
    years of development remains speedy and understandable. I note it is easier
    to compile a program in Go than reply to an email chain in the
    ^&%&$GoogleGroups :-)

    Brett.

    --

    ---
    You received this message because you are subscribed to the Google Groups "golang-dev" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

People

Translate

site design / logo © 2021 Grokbase