subject:"\[9fans\] Go Plan 9"

On Mon, Apr 4, 2011 at 9:22 PM, Russ Cox r...@swtch.com wrote:

 The number of people who want to run Go on Plan 9
 is already small.  The number of people who want to
 run Go on Plan 9 on 9vx is smaller yet.  At that point
 why not just run Go directly?

 9vx is a nice hack but still a hack.

 Russ

 What we need is an OS port of Plan 9 to Go that can run hosted on another
OS or natively.

InfernGo?

Dave

Re: [9fans] Go Plan 9

On Mon, Apr 4, 2011 at 10:11 PM, Russ Cox r...@swtch.com wrote:

  All that Microsoft thinking (99.9%-thinking, if you find the other label
  offensive) to avoid adding a minute, one-off change to the Go runtime?

 It is not a minute, one-off change.
 I don't know how to fix it to cope with tiny virtual address spaces
 like those in 9vx.  It's not something I anticipated when I wrote the
 allocator, and it's not something I really want to spend time on
 for such a tiny fraction of use cases.  We have limited time.
 We don't even support OS X 10.5 anymore.


I'm not sure apple support OS X 10.5 anymore either?  I think that's why the
OS updates are so inexpensive :-)  (what was it like 40 bucks to go from
10.5 to 10.6?)



 The best answer might be to make USTKTOP 1GB.

 Russ

Re: [9fans] Go Plan 9

2011-04-05 Thread erik quanstrom

  What we need is an OS port of Plan 9 to Go that can run hosted on another
 OS or natively.
 
 InfernGo?

huh?

- erik

Re: [9fans] Go Plan 9

On Tue, Apr 5, 2011 at 10:36 AM, erik quanstrom quans...@labs.coraid.comwrote:

   What we need is an OS port of Plan 9 to Go that can run hosted on
 another
  OS or natively.
 
  InfernGo?

 huh?

 - erik


Inferno-like Go based OS (instead of Limbo??)

Not necessarily with any kind of virtual machine but it could be a neat
project...

Re: [9fans] Go Plan 9

2011-04-05 Thread andrey mirtchovski

 InfernGo?

Goribund ;)

Re: [9fans] Go Plan 9

2011/4/5 andrey mirtchovski mirtchov...@gmail.com

  InfernGo?

 Goribund ;)


What a positive sounding project name!

Re: [9fans] Go Plan 9

2011-04-05 Thread Yaroslav

2011/4/5 Lucio De Re lu...@proxima.alt.za:
 As for not running Go on 9vx, that's a pain, I have such a nice 9vx
 installation on my Ubuntu 32-bit laptop that it almost fools me into
 believing it's Plan 9.  I don't always have a convenient CPU server at
 hand to run Go on it.

Why not to run Go directly on your Ubuntu laptop – without the 9vx abstraction?

Re: [9fans] Go Plan 9

2011-04-05 Thread Paul Lalonde

So I can write go programs that take advantage of private namespaces and
other Plan9 innovations.

Paul

On Tue, Apr 5, 2011 at 12:06 PM, Yaroslav yari...@gmail.com wrote:

 2011/4/5 Lucio De Re lu...@proxima.alt.za:
  As for not running Go on 9vx, that's a pain, I have such a nice 9vx
  installation on my Ubuntu 32-bit laptop that it almost fools me into
  believing it's Plan 9.  I don't always have a convenient CPU server at
  hand to run Go on it.

 Why not to run Go directly on your Ubuntu laptop – without the 9vx
 abstraction?




-- 
I'm migrating my email.  plalo...@telus.net will soon be disconnected.
 Please use paul.a.lalo...@gmail.com from now on.

Re: [9fans] Go Plan 9

2011-04-04 Thread Pavel Zholkover

Thanks for the detailed explanation, I've added your patch to if that
is alright with you https://bitbucket.org/paulzhol/golang-plan9-
runtime-patches/

Pavel

On Mon, Apr 4, 2011 at 1:30 AM, Anthony Martin al...@pbrane.org wrote:
 Pavel Zholkover paulz...@gmail.com once said:
 I'm not sure I understand the reason 9vx will fail to reserve 768mb
 with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
 fine, as long as it is not written to.

 The reason is because 9vx gives user processes a virtual
 address space of only 256mb.  The brk works but the
 first time we fault one of those pages past USTKTOP the
 program suicides.

 The first fault happens at src/pkg/runtime/mcache.c:21
 in the runtime·MCache_Alloc function.

 To show you what I mean, here's a formatted stack trace:

 term% cat y.go
 package main

 func main() {
        println(Hello, world.)
 }

 term% ./8.out
 8.out 174: suicide: sys: trap: page fault pc=0x21df

 term% db 8.out 174
 386 binary
 page fault
 /go/src/pkg/runtime/mcache.c:21 runtime.MCache_Alloc+39/        MOVL    
 0(AX),AX
 $c
 runtime.MCache_Alloc(sizeclass=0x1, c=0x30424000, size=0x8, zeroed=0x1)
        /go/src/pkg/runtime/mcache.c:13 called from runtime.mallocgc+db
        /go/src/pkg/runtime/malloc.goc:62
 runtime.mallocgc(size=0x8, zeroed=0x1, flag=0x0, dogc=0x0)
        /go/src/pkg/runtime/malloc.goc:40 called from runtime.malloc+41
        /go/src/pkg/runtime/malloc.goc:115
 runtime.malloc(size=0x1)
        /go/src/pkg/runtime/malloc.goc:113 called from runtime.mallocinit+e9
        /go/src/pkg/runtime/malloc.goc:319
 runtime.mallocinit()
        /go/src/pkg/runtime/malloc.goc:237 called from runtime.schedinit+39
        /go/src/pkg/runtime/proc.c:122
 runtime.schedinit()
        /go/src/pkg/runtime/proc.c:113 called from _rt0_386+b3
        /go/src/pkg/runtime/386/asm.s:78
 _rt0_386()
        /go/src/pkg/runtime/386/asm.s:12 called from 1


 Cheers,
  Anthony

Re: [9fans] Go Plan 9

On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom quans...@labs.coraid.com wrote:
 The reason it doesn't work on 9vx is because the 32 bit Go runtime
 reserves a large chunk of address space (currently 768mb).  On all
 other platforms, this is accomplised with an mmap equivalient, which
 we all know won't work on Plan 9.


 if i read the thread on this topic correctly, this reservation
 isn't necessary on plan 9, since there are no shared libraries
 and the heap will always be contiguous.


no, the shared libraries are not going to affect the heap size.
Certainly not to this scale.

My understanding was that Go used this large sparse address space to
effect for its garbage collection; the fact that it is backed by mmap
of anonymous memory is what makes it work, since pages are not
allocated until touched. Russ?

ron

Re: [9fans] Go Plan 9

2011-04-04 Thread erik quanstrom

On Mon Apr  4 11:19:37 EDT 2011, rminn...@gmail.com wrote:
 On Sun, Apr 3, 2011 at 2:24 PM, erik quanstrom quans...@labs.coraid.com 
 wrote:
  The reason it doesn't work on 9vx is because the 32 bit Go runtime
  reserves a large chunk of address space (currently 768mb).  On all
  other platforms, this is accomplised with an mmap equivalient, which
  we all know won't work on Plan 9.
 
 
  if i read the thread on this topic correctly, this reservation
  isn't necessary on plan 9, since there are no shared libraries
  and the heap will always be contiguous.
 
 
 no, the shared libraries are not going to affect the heap size.
 Certainly not to this scale.
 

i'm not quite sure what you're saying no to.

in any event, my understanding is, it's not the size of
the heap, it's the heap's continuity.  if the heap
is not contiguous, you'll need a structure tracking it.
according to lwn http://lwn.net/Articles/428100/

In the process of trying to reach that goal of
low enough overhead and no significant latency, the
Go developers have made some simplifying assumptions,
one of which is that the memory being managed
for a running application comes from a
single, virtually-contiguous address range.

this is the whole point of the big allocation, so why
would we drag this into plan 9, when it's not necessary.
the plan 9 heap is contiguous.

- erik

Re: [9fans] Go Plan 9

On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote:
 
 Thanks for the detailed explanation, I've added your patch to if that
 is alright with you https://bitbucket.org/paulzhol/golang-plan9-
 runtime-patches/
 
May I suggest that we identify Go executables, because they may not run
under 9vx, as different from Plan 9 executables and adjust the Plan 9
kernel to identify these and avoid running them under 9vx?

There will be changes to Plan 9 to match the Go toolchain, this one is
really small and could be seen as acceptance of Go as part of Plan 9's
future.  Ideally, when the Go runtime no longer needs special treatment
we can re-categorise Go executables as normal Plan 9 executables.
That option moves into the hands of the Go developers, which to me seems
like the right place.

The other one I would like to submit as a patch affects /386/include/u.h
(and other architectures), involving the addition of integer types of
various length.  Equally small and benign.

Opinions?

++L

PS: Would anybody like to summarise for us plebs whether there is any
convergence looming between Go and Plan 9 on the x64 front?  It seems
sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit
toolchain to Plan 9.

Re: [9fans] Go Plan 9

2011-04-04 Thread Pavel Zholkover

On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re lu...@proxima.alt.za wrote:
 PS: Would anybody like to summarise for us plebs whether there is any
 convergence looming between Go and Plan 9 on the x64 front?  It seems
 sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit
 toolchain to Plan 9.

the basic runtime support (not the current syscall and os changes)
involved changes to 8l and some C and 386 specific assembly in
pkg/runtime. I guess this could be re-done for 6l + x64 code in
runtime. The question is whether it is a useful application of
developers time at this stage (it would be still cross-compiled) and
the 386 runtime has not been properly tested.

Pavel

Re: [9fans] Go Plan 9

2011-04-04 Thread Russ Cox

[Sorry for being quiet, I got unsubscribed from 9fans!]

 no, the shared libraries are not going to affect the heap size.
 Certainly not to this scale.

 My understanding was that Go used this large sparse address space to
 effect for its garbage collection; the fact that it is backed by mmap
 of anonymous memory is what makes it work, since pages are not
 allocated until touched. Russ?

The large sparse address space is nice on 64-bit
because you can do some address calculation tricks.
On 32-bit it just doesn't matter.  I think the current
code in package runtime is correct already for Plan 9.

Russ

Re: [9fans] Go Plan 9

On Mon, Apr 04, 2011 at 10:18:12PM +0300, Pavel Zholkover wrote:
 On Mon, Apr 4, 2011 at 8:27 PM, Lucio De Re lu...@proxima.alt.za wrote:
  PS: Would anybody like to summarise for us plebs whether there is any
  convergence looming between Go and Plan 9 on the x64 front?  It seems
  sad to miss a chance to add a peer-reviewed and thoroughly tested 64-bit
  toolchain to Plan 9.
 
 the basic runtime support (not the current syscall and os changes)
 involved changes to 8l and some C and 386 specific assembly in
 pkg/runtime. I guess this could be re-done for 6l + x64 code in
 runtime. The question is whether it is a useful application of
 developers time at this stage (it would be still cross-compiled) and
 the 386 runtime has not been properly tested.
 
I agree that focussing on x64 when there isn't a working target would be
pointless, if intriguing.  I guess the question then belongs in the Plan
9 camp: are we going to see an x64 Plan 9 development soon?  and is the
availability of the 6? chain in the Go sources helpful in arriving there?

++L

Re: [9fans] Go Plan 9

On Mon, Apr 04, 2011 at 07:27:28PM +0200, Lucio De Re wrote:
 On Mon, Apr 04, 2011 at 10:37:30AM +0300, Pavel Zholkover wrote:
  
  Thanks for the detailed explanation, I've added your patch to if that
  is alright with you https://bitbucket.org/paulzhol/golang-plan9-
  runtime-patches/
  
 [ ... ]
 
 The other one I would like to submit as a patch affects /386/include/u.h
 (and other architectures), involving the addition of integer types of
 various length.  Equally small and benign.
 
 Opinions?
 
Here is how I changed u.h for the 386 architecture:

term% diff /n/dump/2011/0130/386/include/u.h /n/dump/2011/0404/386/include/u.h
21a22,34
 /* for the GO toolchain */
 /* (with some effort this could go into /go/386/include,
 but there's really no reason to keep it from the
   native toolchain)
 */
 typedef char int8;
 typedef short int16;
 typedef long int32;
 typedef long long int64;
 typedef unsigned char uint8;
 typedef unsigned short uint16;
 typedef unsigned long uint32;
 typedef unsigned long long uint64;

Seems harmless enough. I'm sure I've actually rebuilt the Plan 9 binaries
in their entirety with these changes and no ill effect.

++L

Re: [9fans] Go Plan 9

On Mon, Apr 4, 2011 at 8:59 AM, erik quanstrom quans...@quanstro.net wrote:

 this is the whole point of the big allocation, so why
 would we drag this into plan 9, when it's not necessary.
 the plan 9 heap is contiguous.

Sorry, Erik, I misunderstood your point.

I guess what you are pointing out is that on Plan 9, presumably, since
the Go runtime is the only thing that might call brk(), it will always
get a virtually contiguous heap. Therefore, instead of a huge upfront
allocation, Go runtime could call brk() as needed.

Can we safely assume that only the Go runtime will call brk()? What if
we link a library into Go that calls brk() as well -- won't that
violate Go's model? Probably not worth worrying about since Russ says
he's good with the other change.

thanks

ron

Re: [9fans] Go Plan 9

On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re lu...@proxima.alt.za wrote:

 May I suggest that we identify Go executables, because they may not run
 under 9vx, as different from Plan 9 executables and adjust the Plan 9
 kernel to identify these and avoid running them under 9vx?


um, yuck :-)

anyway, all you're saying is don't run go on 9vx. That's a solved problem :-)

ron

Re: [9fans] Go Plan 9

2011-04-04 Thread erik quanstrom

 Sorry, Erik, I misunderstood your point.

no need to be sorry.

 I guess what you are pointing out is that on Plan 9, presumably, since
 the Go runtime is the only thing that might call brk(), it will always
 get a virtually contiguous heap. Therefore, instead of a huge upfront
 allocation, Go runtime could call brk() as needed.
 
 Can we safely assume that only the Go runtime will call brk()? What if
 we link a library into Go that calls brk() as well -- won't that
 violate Go's model? Probably not worth worrying about since Russ says
 he's good with the other change.

i didn't think of that, but i wouldn't think one would
want to do that.  the effort, say, to glue ndb structures
into go's world would seem on par with rewriting the library.
and it would be a great oppertunity to clean up some crunch.

one big challenge in gluing in c libraries is that you
couldn't easily pass any sort of pointer back in from c.
it would break the gc.

- erik

Re: [9fans] Go Plan 9

well, Russ has blessed the runtime fix :-)

I look forward to having go in 9vx too!

ron

Re: [9fans] Go Plan 9

I tried a simple hack on 9vx.

First, I had sysbrk_ return the max possible value instead of the
requested value. I.e., if go runtime asked for 768MB, I had it return
something less than TSTKTOP, which is around 256 MB. I like this
because if we change the USTKTOP on 9vx in future we don't have to
recompile the go runtime, and a single binary can run on many 9vx
systems which might have different limits compiled in.

Unfortunately the runtime code ignores the returned value from sbrk_;
strike one.

I then had it return -1 when asked for more memory than could be
returned; Got this:
term% ./testgo.out
throw:

and that was it.

Russ, could the go runtime maybe use the value returned by sbrk
instead of  assuming it got all it asked for?

ron

Re: [9fans] Go Plan 9

2011-04-04 Thread Russ Cox

The number of people who want to run Go on Plan 9
is already small.  The number of people who want to
run Go on Plan 9 on 9vx is smaller yet.  At that point
why not just run Go directly?

9vx is a nice hack but still a hack.

Russ

Re: [9fans] Go Plan 9

On Mon, Apr 04, 2011 at 04:10:15PM -0700, ron minnich wrote:
 
 On Mon, Apr 4, 2011 at 10:27 AM, Lucio De Re lu...@proxima.alt.za wrote:
 
  May I suggest that we identify Go executables, because they may not run
  under 9vx, as different from Plan 9 executables and adjust the Plan 9
  kernel to identify these and avoid running them under 9vx?
 
 
 um, yuck :-)
 
 anyway, all you're saying is don't run go on 9vx. That's a solved problem 
 :-)
 
No, and no yuck, either: Go executables are different animals and
they are allowed to be identified as such.  Until they are not, when
they are allowed to become the same animal.

As for not running Go on 9vx, that's a pain, I have such a nice 9vx
installation on my Ubuntu 32-bit laptop that it almost fools me into
believing it's Plan 9.  I don't always have a convenient CPU server at
hand to run Go on it.

And maybe it's just me being uninformed, but I have this suspicion that
you need a Go toolchain with Plan 9 targets to produce Plan 9 executables.
Maybe I should phrase this as a question: does the default Go toolchain
produce Plan 9 executables or is a separate toolchain required for it?
I'm pretty certain there's a need for two toolchains, but I'll be very
happy to be proven wrong (and Ron right, of course).

The proof would be in the pudding: I tried to compile hell-o.go
(I guess that will become a benchmark :-) under an unadulterated
Go toolchain, then under a Go toolchain built for the Plan 9
target (GOOS=plan9) and the object code produced showed distincly
different sizes.  I don't have the details at my fingertips now,
this is from memory.

And for Cinap, a challenge I wish I had the time and skills to take on
myself: can linuxemu be added as a much thinner shim to 9vx to run Linux
executables?  I can think of one very interesting door that would open,
there may be others.

++L

Re: [9fans] Go Plan 9

On Tue, Apr 05, 2011 at 12:22:18AM -0400, Russ Cox wrote:
 The number of people who want to run Go on Plan 9
 is already small.  The number of people who want to
 run Go on Plan 9 on 9vx is smaller yet.  At that point
 why not just run Go directly?
 
All that Microsoft thinking (99.9%-thinking, if you find the other label
offensive) to avoid adding a minute, one-off change to the Go runtime?
Sure, as Ron suggested it, it may need some additional thought, but we
are talking about the Plan 9 team thinking about it, surely it would
not take long to solve?

 9vx is a nice hack but still a hack.
 
So is VMware, but it may be a breath of life for Plan 9 and adding
features to it seems inexpensive enough.  The same applies to p9p,
which is another toolkit that could benefit from providing a development
environment for Go.

That said, I'd like to make it very clear that I am extremely grateful
to all those who have contributed to making Go available on the Plan 9
platform and that I hope to be part of a growing community.  The current
solution to the 9vx problem seems adequate, one is merely concerned that
it may come back to bite an unsuspecting third party if it is forgotten.

++L

Re: [9fans] Go Plan 9

On Mon, Apr 04, 2011 at 04:33:29PM -0400, erik quanstrom wrote:
 
[ ... ]
 then you can get rid of the old definitions in /*/include/u.h
 and declare a flag day.  having both seems wrong to me.
 you might as well just do a local hack for the go stuff at that
 point.
 
 the hard part is convincing everyone that this large
 patch is worth the pain.
 
 i think it is, but maybe there's something i'm not
 thinking of, or a different point of view.
 
Personally, I like the suggestion, but I think flag days in Plan
9 are best reserved for larger issues than the name of a handful of
type definitions.  The old type names might have been a bad choice (or
a good choice, but contrary to popular opinion), but they do not need
to go away, perhaps they can just be deprecated.  I'm sure the label
wrong is too strong.

++L

Re: [9fans] Go Plan 9

2011-04-04 Thread erik quanstrom

 No, and no yuck, either: Go executables are different animals and

what's different about them? as far as i can tell, they're completely
standard.

- erik

Re: [9fans] Go Plan 9

2011-04-04 Thread Russ Cox

 All that Microsoft thinking (99.9%-thinking, if you find the other label
 offensive) to avoid adding a minute, one-off change to the Go runtime?

It is not a minute, one-off change.
I don't know how to fix it to cope with tiny virtual address spaces
like those in 9vx.  It's not something I anticipated when I wrote the
allocator, and it's not something I really want to spend time on
for such a tiny fraction of use cases.  We have limited time.
We don't even support OS X 10.5 anymore.

The best answer might be to make USTKTOP 1GB.

Russ

Re: [9fans] Go Plan 9

On Tue, Apr 05, 2011 at 01:11:35AM -0400, Russ Cox wrote:
 
  All that Microsoft thinking (99.9%-thinking, if you find the other label
  offensive) to avoid adding a minute, one-off change to the Go runtime?
 
 It is not a minute, one-off change.

I stand corrected.

 I don't know how to fix it to cope with tiny virtual address spaces
 like those in 9vx.  It's not something I anticipated when I wrote the
 allocator, and it's not something I really want to spend time on
 for such a tiny fraction of use cases.  We have limited time.
 We don't even support OS X 10.5 anymore.
 
That is as good an answer as I could possibly ask for.  There will be
other eyes to look at it and hopefully supplement the lack of time.

A quick, uneducated question: should 9vx be investigated instead?

 The best answer might be to make USTKTOP 1GB.
 
Where?

Thanks for replying.

++L

Re: [9fans] Go Plan 9

I've set up a Mercurial patch queue with some instructions on building
at https://bitbucket.org/paulzhol/golang-plan9-runtime-patches/
with Andrey and Taru's patches. I'll try to keep it updated :)

Pavel

Re: [9fans] Go Plan 9

On Sun, Apr 3, 2011 at 2:52 AM, David Leimbach leim...@gmail.com wrote:
 So wait... We can get the toolchain built on plan 9. Or we can target plan 9 
 via cross compiler?  Either way is pretty awesome!  Nice work!

We are cross-compiling unless someone syncs
http://code.google.com/p/go-plan9/ with mainline.

Pavel

Re: [9fans] Go Plan 9

On Apr 3, 2011 12:18 PM, erik quanstrom quans...@quanstro.net wrote:
 okay, i volunteer.  just to make sure, we're talking
 about a plan 9 port, not a cross compile?

 just let me know what i need to get set up.  i can
 easily do 386 and arm at this point.

 - erik

I think Rob meant it would be a cross compile,  at least at first.

Could you comment on your changes at http://code.google.com/p/go-plan9/ ?
Can they be pushed to mainline ?

Pavel

Re: [9fans] Go Plan 9

 Could you comment on your changes at http://code.google.com/p/go-plan9/ ?
 Can they be pushed to mainline ?

i don't think they can in total.  we should push the silly
print format fixes and the added USED() that 8c caught
and gcc didn't.

but there definately are some difficult bits.  this hacked
inclusion of stdio.h is a problem on plan 9.

http://code.google.com/p/go-plan9/source/diff?spec=svnd6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851r=d6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851format=sidepath=/src/cmd/8a/a.y

my solution clearly ignored the problems in pushing
back to the main line.  but at least we have the problem identified.

/src/cmd/8l/l.h has another problem.  we need to figure
out how to get the definitions for uint8, etc from #include u.h
the defines i put in are just wrong, but the alternative is passing in -Isomedir
with a u.h that includes the real u.h and then tweaks other stuff.
that's just wronger.  :-)

a real solution would be one of
0  copy u.h; hack to taste
1  add the hacks to the real u.h
2  come to a concensus with go about what the defined-bit-width
types should be called.  change both plan 9 and go to conform.

i'd vote for 2.  it's harder that way, but i'd hate for go to
feel like it was pasted on.  but i'd like to know what everyone
else thinks.

- erik

Re: [9fans] Go Plan 9

On Sat, Apr 02, 2011 at 07:48:14PM -0700, Rob Pike wrote:
 
 We'll get the Plan 9 implementation up to scratch. It's not there yet,
 though.  Once things look solid we'll need a volunteer to set up a
 builder so we can automatically make sure the Plan 9 port stays
 current.
 
That's code for we'll have a build under Linux for the Plan 9
cross-development system or we'll have a Plan 9 port of Go?

I've been thinking, besides my now very dated efforts to port the Go
toolchain to Plan 9 native, that there may be merit in an intermediate
port of the C and Go toolchains to p9p.  But combining the build
environments looked pretty complicated.  I did try, but I got lost
trying to keep the three build environments (Linux, Plan 9 and p9p)
in my head at the same time.

Still, there may be somebody out there who can get this done better than
I would.

++L

Re: [9fans] Go Plan 9

On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
 
 but there definately are some difficult bits.  this hacked
 inclusion of stdio.h is a problem on plan 9.
 
 http://code.google.com/p/go-plan9/source/diff?spec=svnd6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851r=d6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851format=sidepath=/src/cmd/8a/a.y
 
As GNU says, GNU is not Unix (or Plan 9).  There is no #ifdef-free
way to satisfy both toolchains unless one wants to pervert the Plan 9
toolchain.  One trivial change to GCC, namely Plan 9's use of empty names
to represent unused arguments, would improve GCC greatly, but is unlikely
to be accepted by the developers.  The alternative is a pain in the butt.

But I agree with Erik, the changes to port the Go toolchain to Plan 9
are quite extensive and would require a great deal of care, I have done
a similar job a year ago.  Actually, I think it was two years agon and
I failed to resurrect my efforts a year later.

I'm not sure whether the compiler, assembler and linker that seemed
to work after my first attempts could be used to bootstrap a fresh
source tree.  I put no effort in place on the Go package side, so that
remains to be tried.

In passing, Erik, you made some changes to Yacc to accept //-comments,
do you still have those at hand?  Do you have some idea why they were
not applied to P9 Yacc?

++L

Re: [9fans] Go Plan 9

On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:
 
 a real solution would be one of
 0  copy u.h; hack to taste
 1  add the hacks to the real u.h
 2  come to a concensus with go about what the defined-bit-width
 types should be called.  change both plan 9 and go to conform.
 
 i'd vote for 2.  it's harder that way, but i'd hate for go to
 feel like it was pasted on.  but i'd like to know what everyone
 else thinks.
 
I don't think anything comes near to 2 as a solution.  And it really
isn't all that invasive either.  Add my vote to yours.

++L

Re: [9fans] Go Plan 9

 As GNU says, GNU is not Unix (or Plan 9).  There is no #ifdef-free
 way to satisfy both toolchains unless one wants to pervert the Plan 9
 toolchain.  One trivial change to GCC, namely Plan 9's use of empty names
 to represent unused arguments, would improve GCC greatly, but is unlikely
 to be accepted by the developers.  The alternative is a pain in the butt.

a sed script in the plan9-specific could do the trick.  ideally, though,
the go source wouldn't redefine getc(), and the include could no longer
be necessary.  i've seen go define cget in other places, that might be a
solution; but i don't know the local customs well.

 In passing, Erik, you made some changes to Yacc to accept //-comments,
 do you still have those at hand?  Do you have some idea why they were
 not applied to P9 Yacc?

they have been applied.  thanks to geoff for integrating the
change: /n/sources/patch/applied/yacccmt

- erik

Re: [9fans] Go Plan 9

2011-04-03 Thread Skip Tavakkolian

Why can't we use linuxemu to run the build?

-Skip

On Apr 3, 2011, at 8:43 AM, erik quanstrom quans...@quanstro.net wrote:

 As GNU says, GNU is not Unix (or Plan 9).  There is no #ifdef-free
 way to satisfy both toolchains unless one wants to pervert the Plan 9
 toolchain.  One trivial change to GCC, namely Plan 9's use of empty names
 to represent unused arguments, would improve GCC greatly, but is unlikely
 to be accepted by the developers.  The alternative is a pain in the butt.
 
 a sed script in the plan9-specific could do the trick.  ideally, though,
 the go source wouldn't redefine getc(), and the include could no longer
 be necessary.  i've seen go define cget in other places, that might be a
 solution; but i don't know the local customs well.
 
 In passing, Erik, you made some changes to Yacc to accept //-comments,
 do you still have those at hand?  Do you have some idea why they were
 not applied to P9 Yacc?
 
 they have been applied.  thanks to geoff for integrating the
 change: /n/sources/patch/applied/yacccmt
 
 - erik

Re: [9fans] Go Plan 9

What about the old gcc3 port? Is it enough for bootstrapping the compilers?
On Apr 3, 2011 7:28 PM, Skip Tavakkolian skip.tavakkol...@gmail.com
wrote:

Re: [9fans] Go Plan 9

On Sun, Apr 03, 2011 at 07:49:06PM +0300, Pavel Zholkover wrote:
 What about the old gcc3 port? Is it enough for bootstrapping the compilers?
 On Apr 3, 2011 7:28 PM, Skip Tavakkolian skip.tavakkol...@gmail.com
 wrote:

You'd perpetuate an alien binary format, which sounds like a bad idea
to me.  But I'm so muddled up with all the options, I can't really find
my way out of that paperbag.  So perhaps somebody can pick up where Erik
and I independently left off and make something out of it.  I keep trying,
but it keeps getting more and more complicated, at least to me.

I'm happy to donate all the mkfiles I strung together, but even those
may need major surgery.

++L

Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...
On Apr 3, 2011 11:26 AM, Lucio De Re lu...@proxima.alt.za wrote:
On Sun, Apr 03, 2011 at 06:34:28AM -0400, erik quanstrom wrote:

but there definately are some difficult bits. this hacked
inclusion of stdio.h is a problem on plan 9.

http://code.google.com/p/go-plan9/source/diff?spec=svnd6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851r=d6ec95bd4f9b2e9af2d10f08d9869aa2ca49d851format=sidepath=/src/cmd/8a/a.y

As GNU says, GNU is not Unix (or Plan 9). There is no #ifdef-free
way to satisfy both toolchains unless one wants to pervert the Plan 9
toolchain. One trivial change to GCC, namely Plan 9's use of empty names
to represent unused arguments, would improve GCC greatly, but is unlikely
to be accepted by the developers. The alternative is a pain in the butt.

But I agree with Erik, the changes to port the Go toolchain to Plan 9
are quite extensive and would require a great deal of care, I have done
a similar job a year ago. Actually, I think it was two years agon and
I failed to resurrect my efforts a year later.

I'm not sure whether the compiler, assembler and linker that seemed
to work after my first attempts could be used to bootstrap a fresh
source tree. I put no effort in place on the Go package side, so that
remains to be tried.

In passing, Erik, you made some changes to Yacc to accept //-comments,
do you still have those at hand? Do you have some idea why they were
not applied to P9 Yacc?

++L

Re: [9fans] Go Plan 9

On Sun Apr  3 12:27:29 EDT 2011, skip.tavakkol...@gmail.com wrote:
 Why can't we use linuxemu to run the build?
 

sure we could,  but then you have to maintain linuxemu, and
go.  that seems silly.

 Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...

what does gcc have to do with getting go compiled on plan 9?

- erik

Re: [9fans] Go Plan 9

On Sun, Apr 03, 2011 at 01:43:53PM -0400, Devon H. O'Dell wrote:
 
 Does -fplan9-extensions not do that? Its in the latest gcc for gccgo...

That would be great.  I don't even pretend to keep track of what the GCC
group does, I guess I owe you thanks for correcting me.  If that's how one
goes about finding these things out, well, it's not pretty, but it works.

And in passing that grants me the option to drop unwanted argument names
in the Go sources, but will the Go developers follow suit?  Have they
already done so?  I think I have enough evidence to track down most if
not all instances.

++L

Re: [9fans] Go Plan 9

2011-04-03 Thread Rob Pike

I'm not sure I follow.  The 6c and 6g compilers in the Go distribution
are compiled with the local compiler, such as gcc on Linux and OS X.
I don't believe it's possible they have Plan 9-specific features in
their source.  I can believe they would have problems compiling on
Plan 9, but that's the inverse problem.

Once 6c is built, it is used to build the Go runtime, so the source
and compiler should match perfectly.  Plan 9 compiler issues should
not be relevant.

-rob

Re: [9fans] Go Plan 9

2011-04-03 Thread Steve Simon

A month or so ago I got the go compiler chain to build on plan9,
port is too grand a term, it was just fixing a few nits.

I wrote mkfiles and fixed a few minor bugs. The bigest problem was my knowledge
of yacc was not sufficent to rework the error generation magic go uses from
the bison based code to plan9 yacc code. perhaps there is a yacc expert out 
there
who would be interested in helping?

I am happy to push back my changes, but without either getting yacc to work, or,
abandoning yacc and porting bison, I didn't feel it was ready.

-Steve

Re: [9fans] Go Plan 9

On Sun, Apr 03, 2011 at 11:20:25AM -0700, Rob Pike wrote:
 
 I'm not sure I follow.  The 6c and 6g compilers in the Go distribution
 are compiled with the local compiler, such as gcc on Linux and OS X.
 I don't believe it's possible they have Plan 9-specific features in
 their source.  I can believe they would have problems compiling on
 Plan 9, but that's the inverse problem.
 
On the contrary (if that makes sense), they have that nasty #include
stdio.h that Erik referred to and Plan 9 is allergic to, as well as a
number of nested #includes that trigger rebellion in the Plan 9 toolchain.
And I don't have a 64-bit host to test them on.

But do not forget that I have a Plan 9 native toolchain that compiles
a runnable copy of hello.c, including printf() invocation. It's just
too old to be useful.

 Once 6c is built, it is used to build the Go runtime, so the source
 and compiler should match perfectly.  Plan 9 compiler issues should
 not be relevant.
 
I haven't even considered using the toolchain for Plan 9 native because
I can't track releases given the many changes required to silence the
Plan 9 toolchain.  And maybe some warnings can be overlooked, but I
don't want to be the judge of that.

Basically, I can't find an approach to submitting changes to the Go
toolchain so it can run under Plan 9 that does not involve major surgery,
nor can I separate the changes out in small parcels because testing
is impractical.  I'm hoping that things will eventually settle down and
there will be resources to review extensive, if documentable changes.
Not being able to back-port the Go toolchain to Plan 9 native seems
defeatist.  Now that a runtime is available and will hopefully receive
extensive testing, it makes the exercise even more worthwhile.

And if issues such as compatibility in function argument definitions can
be resolved amicably between the GCC compiler and the Plan 9 toolchain,
then things are really looking up.  But, as I stated earlier, it requires
the will on the Go side to retrofit changes for the sake of Plan 9, and
that may be a problem.  My failed efforts (possibly thoroughly misguided)
to get l.h accepted with changes acceptable to the Plan 9 built-in
pre-processor suggest that the Go developers have different objectives
in mind.

If this does not address Rob's concerns, then I'd like to ask for the
question(s) to be phrased more clearly.

And again, I think one ought to look at all the Plan 9 favours out
there: 9vx deserves effort, Plan9port could support Go better than the
native environment, linuxemu would provide a useful testbench.  Only GCC
3.0 in Plan 9 is almost certainly a dead end.

++L

Re: [9fans] Go Plan 9

On Sun, Apr 03, 2011 at 07:50:20PM +0100, Steve Simon wrote:
 
 A month or so ago I got the go compiler chain to build on plan9,
 port is too grand a term, it was just fixing a few nits.
 
That makes a third version.  I seem to remember Erik's version compiled clean 
and I have to ask Steve now whether his version actually generates Plna 9 
executables.  And, for that matter, how far the Go portion reached.

The version I have restricts itself to C, but has libraries generated using the 
Go toolchain and has produced one non-trivial object code that ran 
successfully.  Regarding the Go compiler and runtime, I seem to remember that 
gc.a was created, but nothing else.

 I wrote mkfiles and fixed a few minor bugs. The bigest problem was my 
 knowledge
 of yacc was not sufficent to rework the error generation magic go uses from
 the bison based code to plan9 yacc code. perhaps there is a yacc expert out 
 there
 who would be interested in helping?
 
When I looked at the Go sources, no such magic stood out, but it's a
long time ago and I may have ignored the problem intentionally.

 I am happy to push back my changes, but without either getting yacc to work, 
 or,
 abandoning yacc and porting bison, I didn't feel it was ready.
 
Maybe Erik, Steve and I should consolidate our changes into a single batch
and submit it as a unit, knowing that it will have received at least some
competent code review.  Anybody else who may want to contribute would,
in my view, be welcome.  Reviewing code intended for Plan 9 cannot be
terribly high within the Google framework at this point in time.

++L

Re: [9fans] Go Plan 9

2011-04-03 Thread Anthony Martin

andrey mirtchovski mirtchov...@gmail.com once said:
 cross-compilation (GOOS=plan9, GOARCH=386, link with -s), but there
 are a few issues -- the build fails at crypto, so fmt is not compiled.
 for a hello world you need to manually make install pkg/strconv and
 pkg/reflect and pkg/fmt.

Everything works fine for me without the '-s' flag.

Pavel Zholkover paulz...@gmail.com once said:
 The produced binaries do not run properly on 9vx since the last gc
 changes so its native or kvm+qemu etc.

The reason it doesn't work on 9vx is because the 32 bit Go runtime
reserves a large chunk of address space (currently 768mb).  On all
other platforms, this is accomplised with an mmap equivalient, which
we all know won't work on Plan 9.

Right now, if you want to run Go binaries on Plan 9, you have to 
apply the patch at the bottom of this message.  In the future we
should probably have the runtime use the segment(3) device.

  Anthony


diff -r 11611373ac8a src/pkg/runtime/malloc.goc
--- a/src/pkg/runtime/malloc.gocSun Apr 03 09:11:41 2011 -0700
+++ b/src/pkg/runtime/malloc.gocSun Apr 03 14:00:13 2011 -0700
@@ -231,7 +231,7 @@
 
 int32 runtime·sizeof_C_MStats = sizeof(MStats);
 
-#define MaxArena32 (2U30)
+#define MaxArena32 (240U20)
 
 void
 runtime·mallocinit(void)
@@ -292,7 +292,7 @@
// kernel threw at us, but normally that's a waste of 512 MB
// of address space, which is probably too much in a 32-bit 
world.
bitmap_size = MaxArena32 / (sizeof(void*)*8/4);
-   arena_size = 51220;
+   arena_size = 6420;

// SysReserve treats the address we ask for, end, as a hint,
// not as an absolute requirement.  If we ask for the end

Re: [9fans] Go Plan 9

2011-04-03 Thread Anthony Martin

Anthony Martin al...@pbrane.org once said:
 Right now, if you want to run Go binaries on Plan 9, you have to 
 apply the patch at the bottom of this message.  In the future we
 should probably have the runtime use the segment(3) device.

That should have been '9vx' instead of 'Plan 9'. Sorry.

  Anthony

Re: [9fans] Go Plan 9

I'm not sure I understand the reason 9vx will fail to reserve 768mb
with brk() while my Plan 9 install on kvm+qemu with 128mb or ram works
fine, as long as it is not written to.

The -s is no longer needed, 8l generates a.out symbols correctly.

Pavel

On Mon, Apr 4, 2011 at 12:16 AM, Anthony Martin al...@pbrane.org wrote:
 Anthony Martin al...@pbrane.org once said:
 Right now, if you want to run Go binaries on Plan 9, you have to
 apply the patch at the bottom of this message.  In the future we
 should probably have the runtime use the segment(3) device.

 That should have been '9vx' instead of 'Plan 9'. Sorry.

  Anthony

Re: [9fans] Go Plan 9