[9fans] Status of port of Go to Plan 9

[9fans] Status of port of Go to Plan 9

[Lucio De Re]

On /n/sources/contrib/lucio/go there is a fresh version of my efforts.
It is a bit ahead of my submissions to the Go Authors and could
benefit from inspection from the Plan 9 perspective.  Also, this
inevitably means that there will be changes required by the code
reviewers.

At this point, it ought to be possible to build the assemblers, C and
Go compilers and linkers for all three architectures (386, amd64 and
arm) for local use on a Plan 9/386 platform.  The only build option I
have tested is the default in src/cmd/mkfile:

	% 9fs sources
	% disk/mkfs -a -s /n/sources/contrib/lucio/go /n/sources/contrib/lucio/go/devproto | disk/mkext -v -d /go
	% cd /go/src/cmd
	% mk

Actual installation should be left until the above succeeds.  Where I
am, multiple downloads are expensive and time consuming, so I can't
test this repetitively, please let me know if the above procedure
needs adjusting:

	% mk install

This ought to copy the 8a, 8c, 8g and 8l executables (not in that
sequence) to /go/386/bin.

I have arranged for the amd64 and arm versions to work as well.
Change to the appropriate directories and the mkfile will provide the
necessary instructions, including installing to /go/386/bin.

Nothing above is properly tested.  Until I get the runtime properly
constructed, I'm not sure how best to go about testing, so any
contribution or suggestions here is welcome.

++L

Re: [9fans] Status of port of Go to Plan 9

[Skip Tavakkolian]

Thanks!

what's a good recipe for making goose? :)

bigtop% mk
# bind -b /go/$objtype/include /$objtype/include
for(i in 8l 8a cc 8c gc 8g) @{
	cd $i
	echo mk in $i
	mk $MKFLAGS
}
mk in 8l
8c -I/go/include -I/go/386/include -FTVw asm.c
8c -I/go/include -I/go/386/include -FTVw ../ld/data.c
mk: no recipe to make 'goos.8' in directory /go/src/cmd/8l
mk: # bind -b ...  : exit status=rc 308216: rc 308218: mk 308220: error

fyi, instead of /go, i've copied it to $home/go and:

aux/stub -d /go
bind -c $home/go /go

-Skip

On Mon, Aug 1, 2011 at 2:04 AM, Lucio De Re <lucio@proxima.alt.za> wrote:
> On /n/sources/contrib/lucio/go there is a fresh version of my efforts.
> It is a bit ahead of my submissions to the Go Authors and could
> benefit from inspection from the Plan 9 perspective.  Also, this
> inevitably means that there will be changes required by the code
> reviewers.
>
> At this point, it ought to be possible to build the assemblers, C and
> Go compilers and linkers for all three architectures (386, amd64 and
> arm) for local use on a Plan 9/386 platform.  The only build option I
> have tested is the default in src/cmd/mkfile:
>
>        % 9fs sources
>        % disk/mkfs -a -s /n/sources/contrib/lucio/go /n/sources/contrib/lucio/go/devproto | disk/mkext -v -d /go
>        % cd /go/src/cmd
>        % mk
>
> Actual installation should be left until the above succeeds.  Where I
> am, multiple downloads are expensive and time consuming, so I can't
> test this repetitively, please let me know if the above procedure
> needs adjusting:
>
>        % mk install
>
> This ought to copy the 8a, 8c, 8g and 8l executables (not in that
> sequence) to /go/386/bin.
>
> I have arranged for the amd64 and arm versions to work as well.
> Change to the appropriate directories and the mkfile will provide the
> necessary instructions, including installing to /go/386/bin.
>
> Nothing above is properly tested.  Until I get the runtime properly
> constructed, I'm not sure how best to go about testing, so any
> contribution or suggestions here is welcome.
>
> ++L
>
>
>

Re: [9fans] Status of port of Go to Plan 9

[Lucio De Re]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

There's a recipe in src/cmd/mkone (../mkone)?

I hope I haven't overlooked any of the mkfiles, it's been a bit of a
swamp for a while.

Have a look at each mkfile's first few lines, you can change ROOT
there or

	mk ROOT=$home/go

but I'm not always propagating (ever?) MKFLAGS.

Let me know, I'll be back in the (local) morning.  Off the cuff, I
don't think you're doing anything wrong, it looks like a context issue
I have not taken into consideration.  But I can't put my finger on it.

++L

[-- Attachment #2: Type: message/rfc822, Size: 5045 bytes --]

From: Skip Tavakkolian <skip.tavakkolian@gmail.com>
To: lucio@proxima.alt.za, Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Status of port of Go to Plan 9
Date: Mon, 1 Aug 2011 11:05:51 -0700
Message-ID: <CAJSxfmJ91P=oYPzu0AENovvXLUGK-Ke0qrODCfWSMOu1SosSrg@mail.gmail.com>

Thanks!

what's a good recipe for making goose? :)

bigtop% mk
# bind -b /go/$objtype/include /$objtype/include
for(i in 8l 8a cc 8c gc 8g) @{
	cd $i
	echo mk in $i
	mk $MKFLAGS
}
mk in 8l
8c -I/go/include -I/go/386/include -FTVw asm.c
8c -I/go/include -I/go/386/include -FTVw ../ld/data.c
mk: no recipe to make 'goos.8' in directory /go/src/cmd/8l
mk: # bind -b ...  : exit status=rc 308216: rc 308218: mk 308220: error

fyi, instead of /go, i've copied it to $home/go and:

aux/stub -d /go
bind -c $home/go /go

-Skip

On Mon, Aug 1, 2011 at 2:04 AM, Lucio De Re <lucio@proxima.alt.za> wrote:
> On /n/sources/contrib/lucio/go there is a fresh version of my efforts.
> It is a bit ahead of my submissions to the Go Authors and could
> benefit from inspection from the Plan 9 perspective.  Also, this
> inevitably means that there will be changes required by the code
> reviewers.
>
> At this point, it ought to be possible to build the assemblers, C and
> Go compilers and linkers for all three architectures (386, amd64 and
> arm) for local use on a Plan 9/386 platform.  The only build option I
> have tested is the default in src/cmd/mkfile:
>
>        % 9fs sources
>        % disk/mkfs -a -s /n/sources/contrib/lucio/go /n/sources/contrib/lucio/go/devproto | disk/mkext -v -d /go
>        % cd /go/src/cmd
>        % mk
>
> Actual installation should be left until the above succeeds.  Where I
> am, multiple downloads are expensive and time consuming, so I can't
> test this repetitively, please let me know if the above procedure
> needs adjusting:
>
>        % mk install
>
> This ought to copy the 8a, 8c, 8g and 8l executables (not in that
> sequence) to /go/386/bin.
>
> I have arranged for the amd64 and arm versions to work as well.
> Change to the appropriate directories and the mkfile will provide the
> necessary instructions, including installing to /go/386/bin.
>
> Nothing above is properly tested.  Until I get the runtime properly
> constructed, I'm not sure how best to go about testing, so any
> contribution or suggestions here is welcome.
>
> ++L
>
>
>

Re: [9fans] Status of port of Go to Plan 9

[Lucio De Re]

> 	mk ROOT=$home/go

	mk 'ROOT='^$home/go

seems better, if uglier :-)

++L

Re: [9fans] Status of port of Go to Plan 9

[Lucio De Re]

> mk in 8l
> 8c -I/go/include -I/go/386/include -FTVw asm.c
> 8c -I/go/include -I/go/386/include -FTVw ../ld/data.c
> mk: no recipe to make 'goos.8' in directory /go/src/cmd/8l
> mk: # bind -b ...  : exit status=rc 308216: rc 308218: mk 308220: error

goos.c is meant to be in src/lib9, I need to start up my laptop to
check that in fact it is a module I added specially for Plan 9.
Nothing else in lib9 is needed, other than a couple of minor
improvements to libc, which I will submit as patches later.

The recipe for goos.8 ought to be in src/cmd/mkone and ought to result
in:

	8c '-DGOOS="plan9"' '-DGOARCH="'^386^'"' '-DGOROOT="'^/go^'"' '-DGOVERSION="'^$"VERSION^'"' -I/go/include -I/go/386/include -FTVw ../../lib9/goos.c

as displayed by mk.  I include this in all executables, probably an
unnecessary sledgehammer.

++L

Re: [9fans] Status of port of Go to Plan 9

[kokamoto]

> goos.c is meant to be in src/lib9, I need to start up my laptop to
> check that in fact it is a module I added specially for Plan 9.

Lucio, what is the difference between your purpose and the one
I installed (plan9fron?).   By your attention, I found Russ's repository
of 'go for plan9', and the one I have installed is not shown there.

According to your mail, you are going to submit your efforts to
golang community, where Russ is one of the big members.
Russ also has been contributed Plan 9 community for a long time.
Then, I suppose anyone will send their patch to Russ...
Many don't know his repository on google?

I'm not a suitable person to develope language, I'll be a user of it.
However, the sceen I'm now experiencing looks like strange to me.

Any considerations?

Kenji

Re: [9fans] Status of port of Go to Plan 9

[Lucio De Re]

>> goos.c is meant to be in src/lib9, I need to start up my laptop to
>> check that in fact it is a module I added specially for Plan 9.
>
> Lucio, what is the difference between your purpose and the one
> I installed (plan9fron?).   By your attention, I found Russ's repository
> of 'go for plan9', and the one I have installed is not shown there.
>
I started with the objective of porting the improved development
toolchain (8a, 8c, 8l) to Plan 9 so that I could use Plan 9 as my
development platform of choice.  Consider that the Go toolchain
includes 6a, 6c and 6l for the x64 as well as tools for the arm, all
there for the picking.  Also, the target platforms are interesting and
increasingly so: various Posix-like OSes, including Darwin, Windows
and Native Client (NaCl).  That was my original attraction, not least
ELF output format, which I have shoehorned into an odish version of
the Plan 9 kernel but was unable to test (who knows what good that
might do!).

I discovered that the Go release is quite a moving target and chose to
feed back to the Go Authors as many of the changes to the Go release
sources as they were willing to accept.  We have made considerable
progress as a result and both sides have hopefully benefitted from my
efforts, which are continuing as we speak.

The difference from the plan9front release of Go is that the latter
is, as far as I understand, a one-off effort which will become more
and more difficult to maintain over time.  I have been there myself,
although I have not been as successful; worse, it was hard for me to
go forward after a pause of a few months, I do not envy the next
person to follow that path.

Please treat the above as opinion, I have not had the opportunity to
investigate the plan9front port of Go and I am basing my opinions on
what I have heard from others.

> According to your mail, you are going to submit your efforts to
> golang community, where Russ is one of the big members.
> Russ also has been contributed Plan 9 community for a long time.
> Then, I suppose anyone will send their patch to Russ...
> Many don't know his repository on google?
>
Russ has been an extremely helpful reviewer of the stuff I have
submitted to the Go Authors, he and I have successfully negotiated a
number of differences of opinion and my efforts in future ought to be
easier because of his assistance.  Any stumbles at this stage are
entirely of my own making.

> I'm not a suitable person to develope language, I'll be a user of it.
> However, the sceen I'm now experiencing looks like strange to me.
>
> Any considerations?
>
> Kenji

The end product I envisage is a convergence of the Go release with its
Plan 9 port, ideally by including all necessary elements in the Go
distribution.  But we're a long way from there, the current Go
distribution is heavily oriented towards compiling using GCC which
means that providing a parallel build using tools that are very
closely related to the very tools that are being generated, is an
ambitious objective.  At this point this is also to some extent in
conflict with the present approach.  Nevermind that bash is also used
extensively in the build, which creates another significant barrier
between the two environments.

So you'll need to forgive me if my approach is slow and seemingly
unfruitful, the distant objectives are more important to me than
immediate gratification.  In my defence, progress is being made and
there is room for contribution.  The use of Code Review as set up
specifically for purposes such as this is the key to my approach and
others are welcome to participate.

Note that I'm not a language developer either.  Programming languages
are a facet of my interest in Computer Science, but in this case my
efforts are almost mechanical, a port to Plan 9 without much effort
towards enhancing the code under consideration.  This is one of the
agreed compromises between me and Russ, he convinced me that changes
to the code base at this point ought to be kept to a minimum.
Eventually, I intend to break out of that jail, but right now I
believe that Russ' approach is best for both parties.  In passing,
will you please post the URL for "his repository on google" you
mention above?  I may be one of those many who do not know about it
(unless of course you're speaking of the official Mercurial
repository).

Feel free to ask for any additional explanations.

++L

Re: [9fans] Status of port of Go to Plan 9

[Lucio De Re]

> what's a good recipe for making goose? :)

I omitted

(src)
	(...)
	lib9
		goos.c

from /go/devproto.  Please add goos.c and its containing directory.

++L

Re: [9fans] Status of port of Go to Plan 9

[Lucio De Re]

>> what's a good recipe for making goose? :)
>
> I omitted
>
> (src)
> 	(...)
> 	lib9
> 		goos.c
>
> from /go/devproto.  Please add goos.c and its containing directory.
>
There are one or two gotchas.  I have tidied up, but they may be
lurking on your system from earlier instances:

 1.	src/cmd/gc/mkopnames.rc must have execute permissions, make
	sure it does.
 2.	src/cmd/gc/opnames.h may have been built with zero size if
	mkopnames.rc did not have execute permissions.  Delete it if
	that is the case, it will be rebuilt.
 3.	src/cmd/gc/y.tab.[ch] may be wrong: the correct versions are
	much bigger than a few hundred bytes, get fresh copies if you
	have the smaller ones.

These problems have tripped me, not only Skip.

There is a remaining known problem.  The yacc targets,
src/cmd/gc/y.tab.[ch], have to be built using GNU Bison, at least
until I get the nerve to add the error file to yacc or to use fgb's
infrastructure to build GNU Bison on Plan 9.  I recommed that you
generate recent versions of these files on a Go target and copy them
to a safe spot from where you can retrieve them as needed.  The
"mkone" clean target deletes them and changing that will create its
own brand of problems.

I'm waiting for the next set of problems I don't yet know about :-)

++L

Re: [9fans] Status of port of Go to Plan 9

[kokamoto]

> Feel free to ask for any additional explanations.

Thank you very much, Lucio for your nice answer to my question.
Now I think I got it right.

Plan9front's porting is just one shot.   However, it's very nice one shot,
because I can do, say, 'godoc image' on my Plan 9 system.
All the neccessary commands can be compiled on my Plan 9 system, etc.

I hope you could get good success on your trail soon, Lucio.
Until your effort' success, I'll use plan9front version of go port.

Kenji

PS. I'll retire at next March, I'll have some duty still.  However, it may be
smaller.   Then, I may be able to use my time after next April.
Now, I'm a geologist here.☺

Re: [9fans] Status of port of Go to Plan 9

[Lucio De Re]

> Plan9front's porting is just one shot.   However, it's very nice one shot,
> because I can do, say, 'godoc image' on my Plan 9 system.
> All the neccessary commands can be compiled on my Plan 9 system, etc.
> 
Well, I hope I didn't state this too strongly, I certainly have only
indirect evidenmce of this.

> I hope you could get good success on your trail soon, Lucio.
> Until your effort' success, I'll use plan9front version of go port.
> 
Please do and let the developers know; I would appreciate that, I'm
sure so would they.

> Kenji
> 
> PS. I'll retire at next March, I'll have some duty still.  However, it may be
> smaller.   Then, I may be able to use my time after next April.
> Now, I'm a geologist here.☺

I, for one, find testing very unappetising so any feedback from the
audience is welcome, specially from knowledgeable sources.  I believe
I'm not unique.

++L