compiler work branches

5584 views
Skip to first unread message

Russ Cox

unread,
Nov 20, 2020, 12:28:35 PM11/20/20
to golang-dev
Hi all,

[This mail is a heads up about ongoing compiler development; no action required.]

The freeze is going well, and we are looking ahead to getting large changes ready to merge when the window opens at the start of the release, as we do for all large changes. In the compiler, we are working on two different large changes: 

- register ABI work to land at the start of Go 1.17 (Feb 1 2021 work begins, Aug 1 2021 release)
- type parameters work to land at the start of Go 1.18 (Aug 1 2021 work begins, Feb 1 2022 release)

We are landing register ABI work in dev.regabi and type parameter work in dev.typeparams. The former is new. Up until now, we were merging master into dev.typeparams. Starting now, we'll merge master into dev.regabi and dev.regabi into dev.typeparams. When Go 1.17 opens, we will merge dev.regabi into master and be back down to just dev.typeparams.

Type parameters will require a lot of new work in the compiler frontend, and we've prototyped some cleanups to cmd/compile that will make that a lot easier and less error-prone. Roughly speaking, the cleanups are (1) replacing Mpint, Mpfloat etc with the go/constant package, (2) replacing cmd/compile/internal/types with types2, and (3) replacing Node with more specific data structures and interfaces. Again, the rationale for these changes is to make the typeparams work easier and less error-prone, and so the changes are limited to that as well.

The cleanups will edit approximately every line of code in cmd/compile/internal/gc. If we landed that work onto dev.typeparams, we'd then have to merge all the dev.regabi work along with all Go 1.17 development into that edited code, which would be rife with error-prone merge conflicts. Instead, we plan to land the cleanups in dev.regabi, so that they will land at the start of Go 1.17. Similarly, wherever we can add new functionality to cmd/compile in support of type parameters that makes sense to land in Go 1.17, we will do it in the dev.regabi branch, to reduce the divergence between Go 1.17 and dev.typeparams and therefore the amount of merging work required over the next 8 months.

We are keeping these branches limited to just the work described above. Please don't send CLs to dev.regabi or dev.typeparams that are unrelated to the register work, the type parameter work, or the (limited scope) cleanup. Such unrelated work should be merged directly to master when the main tree opens.

Again, the point of this mail is just to give a heads up for people who watch Gerrit closely and wonder about the rationale behind the activity on the two branches over the next while. No action is required.

Thanks.

Best,
Russ

Gediminas Bukauskas

unread,
Nov 21, 2020, 4:02:09 AM11/21/20
to golang-dev

 GO has first-class functions and it will make implementation of type parameters very complicated in real compiler. Look at C#: Microsoft some years ago promised to prepare compiler from MSIL into native machine codes. This idea failed because the language has type parameters and delegates. It will be nice if you’ll find the solution but I am afraid that it is impossible.

You would implement C style macro-commands instead of wasting time on very complicated problem. Two-pass compiler will supply even more flexible solutions for creating containers and generic functions comparing it with parameterized types. Moreover you can use solutions that are published in GCC compiler’s sources.


Gediminas Bukauskas

gbuka...@gmail.com

SKYPE: gediminasbuk

Ian Lance Taylor

unread,
Nov 21, 2020, 8:58:33 AM11/21/20
to Gediminas Bukauskas, golang-dev
I changed the Subject line as this message is not really related to
the message to which it is replying.


On Sat, Nov 21, 2020 at 1:02 AM Gediminas Bukauskas
<gbuka...@gmail.com> wrote:
>
> GO has first-class functions and it will make implementation of type parameters very complicated in real compiler. Look at C#: Microsoft some years ago promised to prepare compiler from MSIL into native machine codes. This idea failed because the language has type parameters and delegates. It will be nice if you’ll find the solution but I am afraid that it is impossible.
>
> You would implement C style macro-commands instead of wasting time on very complicated problem. Two-pass compiler will supply even more flexible solutions for creating containers and generic functions comparing it with parameterized types. Moreover you can use solutions that are published in GCC compiler’s sources.

I believe that the current type parameters design draft avoids any
problems with first class functions by simply not permitting them to
have type parameters. Type parameters are only permitted on top level
function and type definitions.

If you think there is still a problem here, can you explain further? Thanks.

Ian
Reply all
Reply to author
Forward
0 new messages