code review 65220044: runtime: use goc2c as much as possible

runtime: use goc2c as much as possible

Package runtime's C functions written to be called from Go
started out written in C using carefully constructed argument
lists and the FLUSH macro to write a result back to memory.

For some functions, the appropriate parameter list ended up
being architecture-dependent due to differences in alignment,
so we added 'goc2c', which takes a .goc file containing Go func
declarations but C bodies, rewrites the Go func declaration to
equivalent C declarations for the target architecture, adds the
needed FLUSH statements, and writes out an equivalent C file.
That C file is compiled as part of package runtime.

Native Client's x86-64 support introduces the most complex
alignment rules yet, breaking many functions that could until
now be portably written in C. Using goc2c for those avoids the
breakage.

Separately, Keith's work on emitting stack information from
the C compiler would require the hand-written functions
to add #pragmas specifying how many arguments are result
parameters. Using goc2c for those avoids maintaining #pragmas.

For both reasons, use goc2c for as many Go-called C functions
as possible.

This CL is a replay of the bulk of CL 15400047 and CL 15790043,
both of which were reviewed as part of the NaCl port and are
checked in to the NaCl branch. This CL is part of bringing the
NaCl code into the main tree.

No new code here, just reformatting and occasional movement
into .h files.

[rsc, 2014-02-18 03:37:00]

Hello dave@cheney.net (cc: golang-codereviews@googlegroups.com, r),

I'd like you to review this change to
https://code.google.com/p/go/

[brainman, 2014-02-18 05:15:04]

In CL description you have double "from":

...
Separately, Keith's work on emitting stack information from
from the C compiler ...

Alex

[rsc, 2014-02-19 15:02:03]

Hello dave@cheney.net, alex.brainman@gmail.com (cc:
golang-codereviews@googlegroups.com, r@golang.org),

Please take another look.

[brainman, 2014-02-19 23:33:10]

This is a large change ...

https://codereview.appspot.com/65220044/diff/60001/src/cmd/dist/buildruntime.c
File src/cmd/dist/buildruntime.c (right):

https://codereview.appspot.com/65220044/diff/60001/src/cmd/dist/buildruntime....
src/cmd/dist/buildruntime.c:373: "defs.c",
Cannot see any defs.c. Have you forgotten to add it to this CL?

https://codereview.appspot.com/65220044/diff/60001/src/cmd/dist/goc2c.c
File src/cmd/dist/goc2c.c (right):

https://codereview.appspot.com/65220044/diff/60001/src/cmd/dist/goc2c.c#newco...
src/cmd/dist/goc2c.c:96: int rnd;
small comment would help people like me

https://codereview.appspot.com/65220044/diff/60001/src/pkg/runtime/hashmap.goc
File src/pkg/runtime/hashmap.goc (left):

https://codereview.appspot.com/65220044/diff/60001/src/pkg/runtime/hashmap.go...
src/pkg/runtime/hashmap.goc:15: // The map is just a hash table.  The data is
arranged
What happened to this comment and all defines?

[dave_cheney.net, 2014-02-20 19:38:35]

I think defs.c is missing. This wouldn't compile cleanly for me yesterday. 

Dave

> On 20 Feb 2014, at 2:02, rsc@golang.org wrote:
> 
> Hello dave@cheney.net, alex.brainman@gmail.com (cc:
> golang-codereviews@googlegroups.com, r@golang.org),
> 
> Please take another look.
> 
> 
> https://codereview.appspot.com/65220044/

[rsc, 2014-02-20 20:51:31]

I added chan.h, hashmap.h, and defs.c. Sorry.

[r, 2014-02-20 20:54:21]

LGTM

[rsc, 2014-02-20 20:58:54]

*** Submitted as https://code.google.com/p/go/source/detail?r=63484e8b6b76 ***

runtime: use goc2c as much as possible

Package runtime's C functions written to be called from Go
started out written in C using carefully constructed argument
lists and the FLUSH macro to write a result back to memory.

For some functions, the appropriate parameter list ended up
being architecture-dependent due to differences in alignment,
so we added 'goc2c', which takes a .goc file containing Go func
declarations but C bodies, rewrites the Go func declaration to
equivalent C declarations for the target architecture, adds the
needed FLUSH statements, and writes out an equivalent C file.
That C file is compiled as part of package runtime.

Native Client's x86-64 support introduces the most complex
alignment rules yet, breaking many functions that could until
now be portably written in C. Using goc2c for those avoids the
breakage.

Separately, Keith's work on emitting stack information from
the C compiler would require the hand-written functions
to add #pragmas specifying how many arguments are result
parameters. Using goc2c for those avoids maintaining #pragmas.

For both reasons, use goc2c for as many Go-called C functions
as possible.

This CL is a replay of the bulk of CL 15400047 and CL 15790043,
both of which were reviewed as part of the NaCl port and are
checked in to the NaCl branch. This CL is part of bringing the
NaCl code into the main tree.

No new code here, just reformatting and occasional movement
into .h files.

LGTM=r
R=dave, alex.brainman, r
CC=golang-codereviews
https://codereview.appspot.com/65220044

[gobot, 2014-02-20 22:32:07]

This CL appears to have broken the plan9-386-cnielsen builder.