[9fans] GNU/Linux/Plan 9 disto

[9fans] GNU/Linux/Plan 9 disto

[rbnsw-plan9]

Not to rain on anyone's summer of code project but I think producing a Linux distro that runs on top of Plan 9 would be more beneficial to the Plan 9's future than a Plan 9 userspace on top of Glendix, though nowhere as interesting.

I've no problem with a kernel that could run both Plan 9 and Linux binaries but if your goal is that Plan 9 binaries run unchanged on such a system then you will require some sort of device mapping layer, say a FUSE file system that makes Linux devices look like their Plan 9 counterparts - the chief problem being mapping between Linux ioctls and the Plan 9 ctl file protocols.

While you could do that, I have my doubts as to how complete this would be and whether it would be maintained. Moreover, it doesn't do anything to cause Linux and Plan 9 to converge. Since it is difficult to make ioctl work over the network unless source and destination have the same binary architecture Linux needs to be encouraged to change to be closer to the Plan 9 device  model, or at least to a portable ioctl model. Providing a mapping layer just entrenches the problem with Linux and moves Linux no closer to a solution.

Unfortunately, even though there are clustering solutions available which even address process migration Linux people seems quite happy to address remote device access with ad hoc solutions. 

I see a GNU/Linux/Plan 9 distro as making Plan 9 more appealing to the greater public and to aid its domination. Screw fixing Linux to be more Plan 9 like, lets assume Plan 9 has won and the rest is a mere implementation detail. Perhaps some of users attracted buy such a disto will be encouraged to add Plan 9 support for their devices or modify Linux libraries to access Plan 9 natively rather than via Linux emulation. Nothing should be removed, where Plan 9 does something in a perfectly acceptable and sensibly complete way it should be the only mechanism provided (in the long term at least) and the Linux code reliant on the missing mechanism ported to work natively with Plan 9 - unless it is much less work to emulate whatever is missing. To take code using ioctl as an example, the code should be refactored so that both a Plan 9 and Linux libraries with a portable interface are produced, and the modified Linux source and libraries submitted to the current
 maintainers. However, standard C wchar_t based programs probably should be left alone rather the modified to use the Plan 9 string processing model.

Now just for the hell of it, let imagine a world where clustering solutions are built on a Plan 9 base. I'd certainly like something where my local processes migrate from my lower powered laptop including the Window manager migrate to a more powerful CPU when it becomes available and back again when my laptop becomes disconnected,

Now, if I ever can decide on a Linux distribution and ever get Plan 9 to boot, I will see what I can do...

Re: [9fans] GNU/Linux/Plan 9 disto

[Jens Staal]

Personally, I believe that a Plan9 target for a cross compiler might
be more interesting. GCC already added support for the Plan9 dialect
of C. If it also could be made to compile Plan9 binaries, it could be
used for an alternative self-hosting distro as the one you envisaged.

I am fully aware that this is quite herretic and probably not very
interesting for mainline Plan9.

2011/7/11  <rbnsw-plan9@yahoo.com.au>:
> Not to rain on anyone's summer of code project but I think producing a Linux distro that runs on top of Plan 9 would be more beneficial to the Plan 9's future than a Plan 9 userspace on top of Glendix, though nowhere as interesting.
>
> I've no problem with a kernel that could run both Plan 9 and Linux binaries but if your goal is that Plan 9 binaries run unchanged on such a system then you will require some sort of device mapping layer, say a FUSE file system that makes Linux devices look like their Plan 9 counterparts - the chief problem being mapping between Linux ioctls and the Plan 9 ctl file protocols.
>
> While you could do that, I have my doubts as to how complete this would be and whether it would be maintained. Moreover, it doesn't do anything to cause Linux and Plan 9 to converge. Since it is difficult to make ioctl work over the network unless source and destination have the same binary architecture Linux needs to be encouraged to change to be closer to the Plan 9 device  model, or at least to a portable ioctl model. Providing a mapping layer just entrenches the problem with Linux and moves Linux no closer to a solution.
>
> Unfortunately, even though there are clustering solutions available which even address process migration Linux people seems quite happy to address remote device access with ad hoc solutions.
>
> I see a GNU/Linux/Plan 9 distro as making Plan 9 more appealing to the greater public and to aid its domination. Screw fixing Linux to be more Plan 9 like, lets assume Plan 9 has won and the rest is a mere implementation detail. Perhaps some of users attracted buy such a disto will be encouraged to add Plan 9 support for their devices or modify Linux libraries to access Plan 9 natively rather than via Linux emulation. Nothing should be removed, where Plan 9 does something in a perfectly acceptable and sensibly complete way it should be the only mechanism provided (in the long term at least) and the Linux code reliant on the missing mechanism ported to work natively with Plan 9 - unless it is much less work to emulate whatever is missing. To take code using ioctl as an example, the code should be refactored so that both a Plan 9 and Linux libraries with a portable interface are produced, and the modified Linux source and libraries submitted to the current
>  maintainers. However, standard C wchar_t based programs probably should be left alone rather the modified to use the Plan 9 string processing model.
>
> Now just for the hell of it, let imagine a world where clustering solutions are built on a Plan 9 base. I'd certainly like something where my local processes migrate from my lower powered laptop including the Window manager migrate to a more powerful CPU when it becomes available and back again when my laptop becomes disconnected,
>
> Now, if I ever can decide on a Linux distribution and ever get Plan 9 to boot, I will see what I can do...
>
>
>

Re: [9fans] GNU/Linux/Plan 9 disto

[Gorka Guardiola]

On Mon, Jul 11, 2011 at 6:41 PM, Jens Staal <staal1978@gmail.com> wrote:
> Personally, I believe that a Plan9 target for a cross compiler might
> be more interesting. GCC already added support for the Plan9 dialect
> of C. If it also could be made to compile Plan9 binaries, it could be
> used for an alternative self-hosting distro as the one you envisaged.
>
> I am fully aware that this is quite herretic and probably not very
> interesting for mainline Plan9.
>

Not a religion, whatever works for you.

Notice though that the kernel and applications need
some more that only the extensions. All of it (including the
assembler) is written supposing caller save
and other inner specifics of kencc that would need to be dealt with
when compiling
for gcc. It would be a port, not only a recompilation.

G.

Re: [9fans] GNU/Linux/Plan 9 disto

[Charles Forsyth]

setting up cross-compilation with gcc, and even using it once set up,
has historically been surprisingly complicated; has that changed?

Re: [9fans] GNU/Linux/Plan 9 disto

[Pavel Zholkover]

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

> setting up cross-compilation with gcc, and even using it once set up,
> has historically been surprisingly complicated; has that changed?
>

I'm not sure about gcc, but the go toolchain can produce quite well working
Plan 9 binaries.

Taru also has the go toolchain running native in itself after some
modifications.

Pavel

[-- Attachment #2: Type: text/html, Size: 378 bytes --]

[9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Tue, Jul 12, 2011 at 08:59:22AM +0300, Pavel Zholkover wrote:
>
> I'm not sure about gcc, but the go toolchain can produce quite well working
> Plan 9 binaries.
>
> Taru also has the go toolchain running native in itself after some
> modifications.
>
Is there a link to this, please?

I want to take this opportunity to inform 9fans that Russ Cox has helped
me extensively to update the Go release so that the source code for
the 386 assembler, linker and C compiler (8a, 8l and 8c) can be built
without further modification on a 386 Plan 9 native platform.  The leap
to the other target CPU architectures (x64 and arm) is small and I have
been preparing the patched sources for it.

The obvious next step is 8g, but I'm holding back on that right now
so that more extensive testing can take place, rather than propagate
bad decisions.

I need some help testing the work so far, even more I need some sound
advice, specifically on how to release the scaffolding needed for the Plan
9 environment without prematurely adding it to the Go release.  At the
moment, I'm using a CVS repository as a poor(stupid?)-man's version
of Mercurial Queues and it is possible that this will continue to be
adequate for a while still; I'm concerned about failure of vision, though.

Putting the repository on "sources" may be one way of propagating my
efforts at this point, but for obvious reasons updates will have to be
submitted on a different channel.  Again, suggestions are welcome.  I do
have Mercurial available on a public server, but I'm not comfortable with
the tool enough to encourage its use at this point, I find grasping all
the facets of revision control provided by mercurial extremely difficult.

As for the testing required, I am looking for confirmation that 8c, 8a
and 8l perform as expected in a Plan 9/386 environment, it is building
this environment that I find hard to do right now, hence my request for
some assistance.  Naturally, this can all be discussed offline.

++L

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Francisco J Ballesteros]

If you could put just a tgz at sources I'm willing to test it,
even for updates, I could just unpack the tgz again and rebuild the thing.
although I don't have much spare time these days and it's likely
I wont be able to help other than by testing (sorry about that).

But it's great news in any case :)
Thanks a lot to you guys.

On Tue, Jul 12, 2011 at 5:13 PM, Lucio De Re <lucio@proxima.alt.za> wrote:
> On Tue, Jul 12, 2011 at 08:59:22AM +0300, Pavel Zholkover wrote:
>>
>> I'm not sure about gcc, but the go toolchain can produce quite well working
>> Plan 9 binaries.
>>
>> Taru also has the go toolchain running native in itself after some
>> modifications.
>>
> Is there a link to this, please?
>
> I want to take this opportunity to inform 9fans that Russ Cox has helped
> me extensively to update the Go release so that the source code for
> the 386 assembler, linker and C compiler (8a, 8l and 8c) can be built
> without further modification on a 386 Plan 9 native platform.  The leap
> to the other target CPU architectures (x64 and arm) is small and I have
> been preparing the patched sources for it.
>
> The obvious next step is 8g, but I'm holding back on that right now
> so that more extensive testing can take place, rather than propagate
> bad decisions.
>
> I need some help testing the work so far, even more I need some sound
> advice, specifically on how to release the scaffolding needed for the Plan
> 9 environment without prematurely adding it to the Go release.  At the
> moment, I'm using a CVS repository as a poor(stupid?)-man's version
> of Mercurial Queues and it is possible that this will continue to be
> adequate for a while still; I'm concerned about failure of vision, though.
>
> Putting the repository on "sources" may be one way of propagating my
> efforts at this point, but for obvious reasons updates will have to be
> submitted on a different channel.  Again, suggestions are welcome.  I do
> have Mercurial available on a public server, but I'm not comfortable with
> the tool enough to encourage its use at this point, I find grasping all
> the facets of revision control provided by mercurial extremely difficult.
>
> As for the testing required, I am looking for confirmation that 8c, 8a
> and 8l perform as expected in a Plan 9/386 environment, it is building
> this environment that I find hard to do right now, hence my request for
> some assistance.  Naturally, this can all be discussed offline.
>
> ++L
>
>

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Tue, Jul 12, 2011 at 08:35:26PM +0200, Francisco J Ballesteros wrote:
> If you could put just a tgz at sources I'm willing to test it,
> even for updates, I could just unpack the tgz again and rebuild the thing.
> although I don't have much spare time these days and it's likely
> I wont be able to help other than by testing (sorry about that).
>
OK, here's my side of things.

I've uploaded to sources the /go hierarchy that, to the best of my
knowledge, should make it possible for a mildly savvy Plan 9 user to
build 8a, 8l and 8c on a 386 platform.

The location is /n/sources/contrib/lucio/go and is meant to install in
the root (at /go, to be specific).  I have hard coded in many mkfiles the
assignment ROOT=/go to keep things simple, so it's easiest to go along
with this convention until somebody puts some effort into improving is.

The test operation I perform is to change directory to /go/src/cmd/8c
and execute "mk".  It ought to execute without problems, but my Plan 9
platform may have some tweaks that I have forgotten, so it's important
to report to me anything unexpected.

If "8c" builds correctly, the executable can be "mk install"ed into
/go/386/bin, off the cuff I'm notsure that this directory is created,
so it may be necessary to check first.  I would need to correct the
"devproto" file (in "/go") to make sure all target directories are in
fact created.

To build your own development environment, I suggest:

	% 9fs sources
	% disk/mkext -a -s /n/sources/contrib/lucio/go /n/sources/contrib/lucio/go/devproto |
		disk/mkext -d /go

There are many inconsistencies I am vaguely aware of, feel free to remind
me and make suggestion on how to improve them.	The mkfiles randomly rely
on GOROOT et al or make their own decisions about where the sources are
installed: they need to be identified, some thought applied and a final
approach decided upon.	/sys/src/cmd/mk* files are used arbitrarily
(these are the ones I remember, others may bite you as well), the idea
is that if we need slight variations we ought to target $ROOT/src/cmd/mk*
instead, but these are early days and there are inconsistencies lurking.

/go/386/include/u.h is particularly of interest: bits of fluff have been
tucked away in there to simplify porting and may appear particularly ugly.

I will try to document all the important details, but like all
programmers, I have a subconscious need to avoid documenting anything
at all costs.  I will reply to all reasonable questions.

Lucio.

PS: I assume there are p9p users here who, like me, believe it would be
advantageous to add the Go toolchain to the p9p distribution.  I'd like
to hear from them.  I can't give that particular task a high priority,
but I'm keen to encourage others to make some progress on that front.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Wed, Jul 13, 2011 at 08:31:58PM +0200, Lucio De Re wrote:
> There are many inconsistencies I am vaguely aware of, feel free to remind
> me and make suggestion on how to improve them.

One problem is the lack of execute permissions, you may have to fix these.

Lucio.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[stephano zanzin]

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

Great! I just came to the list today looking for some content about Go in
p9, I'll code many stuff in Go and was wondering if it was ported. Count me
in for testing and would be much appreciated if you highlight what have been
done to bring 386 Go over Plan 9.

On Wed, Jul 13, 2011 at 3:45 PM, Lucio De Re <lucio@proxima.alt.za> wrote:

> On Wed, Jul 13, 2011 at 08:31:58PM +0200, Lucio De Re wrote:
> > There are many inconsistencies I am vaguely aware of, feel free to remind
> > me and make suggestion on how to improve them.
>
> One problem is the lack of execute permissions, you may have to fix these.
>
> Lucio.
>
>


--
S.

[-- Attachment #2: Type: text/html, Size: 992 bytes --]

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

On Thu, Jul 14, 2011 at 03:59:08PM -0300, stephano zanzin wrote:
>
> Great! I just came to the list today looking for some content about Go in
> p9, I'll code many stuff in Go and was wondering if it was ported. Count me
> in for testing and would be much appreciated if you highlight what have been
> done to bring 386 Go over Plan 9.
>
It is possible to cross-compile Go on Linux for Plan 9, the details are
a bit vague and I, for one, would not mind somebody rehashing them here
or providing a pointer to them.

The stuff I'm working on is nowhere near ready for prime time.  But it's
progress.

++L

PS: I'm assembly a TODO list for my end of the action, I fear it is a
pretty long one :-(

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Iruatã Souza]

http://groups.google.com/group/golang-dev/browse_thread/thread/c44be49fe9ca42e7/cb98571d81888b9f?lnk=gst&q=plan9front#cb98571d81888b9f

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Fazlul Shahriar]

On Thu, Jul 14, 2011 at 4:21 PM, Lucio De Re <lucio@proxima.alt.za> wrote:
> It is possible to cross-compile Go on Linux for Plan 9, the details are
> a bit vague and I, for one, would not mind somebody rehashing them here
> or providing a pointer to them.

I have a script shown below that I source. Then, running ./make.bash
in $GOROOT/src will build and install everything. You can also build
tests using the host system's gotest (run with -c flag). I'm disabling
hg because codereview might attempt to run Plan 9's gofmt, etc, which
won't work and mess up your CL. More details about the environment
variables are here: http://golang.org/doc/install.html#environment

export GOROOT=/s/9vx/go
export GOOS=plan9
export GOARCH=386
export GOHOSTOS=linux
export GOHOSTARCH=386
export GOBIN=$GOROOT/bin
export PATH=$GOROOT/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:/usr/games:$PLAN9/bin
export PS1="goplan9; "
alias goplan9=:
alias gotest=$HOME/go/bin/gotest
alias gofmt=$HOME/go/bin/gofmt
alias hg='echo this is a cross-compile env'

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Lucio De Re]

I've been trying to port (GNU) bison to Plan 9 to make it easier
to get the Go release to compile under the Plan 9 native toolchain.
I needed to take a breather yesterday, it is just oh so frustrating!
Has anyone got bison ported yet?  I suppose I could try linuxemu (hadn't
thought of that!) in desperation, although I think I'll get there with
a fresh effort.

Where are the yacc experts?  The Go release desperately needs a yacc
advocate.  Desperately, as the Go Authors (you know who you are :-)
are hard to persuade when changes to the release are expansive.

I do appreciate their philosophy.  Looking at the amount of work that
goes into Go daily, I'm amazed at how hard they work and at the fact that
they can do any development on top of actively reviewing all submissions.

I was thinking that Google ought to employ someone to do just reviewing
(a small team), as suggested by Fred Brooks in the Mythical Man Month",
but I know that the quality persons required in that role would lose their
minds pretty quickly, no matter how good the tools available to them.

Anyway, I'm unhappily quagmired right now, I'll make some sort of
announcement when I find my way out.

++L

PS: The Go release will eventually slow down, one expects. At that point,
perhaps, one ought to apply a lavish amount of quality control.  Hm,
maybe a wish list can be the first step to that?  I have a few items...

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Ethan Grammatikidis]

On Fri, 22 Jul 2011 06:40:38 +0200
Lucio De Re <lucio@proxima.alt.za> wrote:

> I've been trying to port (GNU) bison to Plan 9 to make it easier
> to get the Go release to compile under the Plan 9 native toolchain.
> I needed to take a breather yesterday, it is just oh so frustrating!
> Has anyone got bison ported yet?  I suppose I could try linuxemu (hadn't
> thought of that!) in desperation, although I think I'll get there with
> a fresh effort.

Go has already been ported by Taru, a fact noted in the thread on
golang-nuts where you announced your intention to try to port Go a
little while ago. Is it so hard as that to see how she did
it?

Source:
http://pkg.violetti.org/src/go-2011.05.10.tbz

Actually, I asked her and she's happy for you to email her with
questions, too. taruti@taruti.net

Sorry if I sound a bit snippy. I have struggled with various compiles
myself and reached the conclusion that any such struggling is pointless
when there's any other way, so it's a bit painful to watch you
struggling to duplicate work already done.

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[kokamoto]

> Source:
> http://pkg.violetti.org/src/go-2011.05.10.tbz

I tried this just now.
It's amazing!
Thanks to the author, and you.

I've been had an interest to Golang.   However, I don't like Mac OSX and Linux.
Yes, I tried them, however....

Now I can look into Golang on my Plan9 system.

Kenji

Re: [9fans] Plan 9 Go (Was: GNU/Linux/Plan 9 disto)

[Skip Tavakkolian]

i can test, i can also give you access to my environment if you want.

-Skip

On Tue, Jul 12, 2011 at 8:13 AM, Lucio De Re <lucio@proxima.alt.za> wrote:
> On Tue, Jul 12, 2011 at 08:59:22AM +0300, Pavel Zholkover wrote:
>>
>> I'm not sure about gcc, but the go toolchain can produce quite well working
>> Plan 9 binaries.
>>
>> Taru also has the go toolchain running native in itself after some
>> modifications.
>>
> Is there a link to this, please?
>
> I want to take this opportunity to inform 9fans that Russ Cox has helped
> me extensively to update the Go release so that the source code for
> the 386 assembler, linker and C compiler (8a, 8l and 8c) can be built
> without further modification on a 386 Plan 9 native platform.  The leap
> to the other target CPU architectures (x64 and arm) is small and I have
> been preparing the patched sources for it.
>
> The obvious next step is 8g, but I'm holding back on that right now
> so that more extensive testing can take place, rather than propagate
> bad decisions.
>
> I need some help testing the work so far, even more I need some sound
> advice, specifically on how to release the scaffolding needed for the Plan
> 9 environment without prematurely adding it to the Go release.  At the
> moment, I'm using a CVS repository as a poor(stupid?)-man's version
> of Mercurial Queues and it is possible that this will continue to be
> adequate for a while still; I'm concerned about failure of vision, though.
>
> Putting the repository on "sources" may be one way of propagating my
> efforts at this point, but for obvious reasons updates will have to be
> submitted on a different channel.  Again, suggestions are welcome.  I do
> have Mercurial available on a public server, but I'm not comfortable with
> the tool enough to encourage its use at this point, I find grasping all
> the facets of revision control provided by mercurial extremely difficult.
>
> As for the testing required, I am looking for confirmation that 8c, 8a
> and 8l perform as expected in a Plan 9/386 environment, it is building
> this environment that I find hard to do right now, hence my request for
> some assistance.  Naturally, this can all be discussed offline.
>
> ++L
>
>

Re: [9fans] GNU/Linux/Plan 9 disto

[Ethan Grammatikidis]

On Mon, 11 Jul 2011 20:31:08 +0100
Charles Forsyth <forsyth@terzarima.net> wrote:

> setting up cross-compilation with gcc, and even using it once set up,
> has historically been surprisingly complicated; has that changed?

Not the last time I tried, a couple of years ago.

I quite liked Gcc when it was at version 2.93 and I wasn't considering cross-compilation. Now I find it sickening even from a purely practical point of view. It's still usable for compiling my own simple code, and where other programmers haven't tried to be clever it will generally produce acceptable results, but..... erg! It makes me shiver. It's like walking through a minefield, except that when things go wrong the only thing that gets hurt is your brain. (And, of course, you can lose a lot of time.)

Re: [9fans] GNU/Linux/Plan 9 disto

[Jens Staal]

Would the the work  already done on the Plan9 binary format and
syscall mapping that has been made for the Glendix kernel be useful as
"documentation" for implementing a Plan9 binary output in GCC?

and in the other direction, would it be useful to make a Plan9 libc
port to compile "real" Plan9 binaries with GCC on Linux? Would this be
mutually more benefitial than the current P9P?

I am waaay out of my league here so sorry if I say something stupid.

 2011/7/11 Gorka Guardiola <paurea@gmail.com>:
> On Mon, Jul 11, 20he11 at 6:41 PM, Jens Staal <staal1978@gmail.com> wrote:
>> Personally, I believe that a Plan9 target for a cross compiler might
>> be more interesting. GCC already added support for the Plan9 dialect
>> of C. If it also could be made to compile Plan9 binaries, it could be
>> used for an alternative self-hosting distro as the one you envisaged.
>>
>> I am fully aware that this is quite herretic and probably not very
>> interesting for mainline Plan9.
>>
>
> Not a religion, whatever works for you.
>
> Notice though that the kernel and applications need
> some more that only the extensions. All of it (including the
> assembler) is written supposing caller save
> and other inner specifics of kencc that would need to be dealt with
> when compiling
> for gcc. It would be a port, not only a recompilation.
>
> G.
>
>

Re: [9fans] GNU/Linux/Plan 9 disto

[erik quanstrom]

> Notice though that the kernel and applications need
> some more that only the extensions. All of it (including the
> assembler) is written supposing caller save
> and other inner specifics of kencc that would need to be dealt with
> when compiling
> for gcc. It would be a port, not only a recompilation.

not only that.  waserror() depends on callee-save.

- erik

Re: [9fans] GNU/Linux/Plan 9 disto

[Charles Forsyth]

>waserror() depends on callee-save.

caller-save, and a few other conventions (or rather, no need for more conventions).
specifically, it's enough to save the pc and stack. all variables will
have the right values on non-zero return from setjmp, regardless of the
presence or absence of "volatile", and that return can be done by
simply setting the pc and the stack pointer to the values in the jmp_buf.

Re: [9fans] GNU/Linux/Plan 9 disto

[Enrico Weigelt]

* Charles Forsyth <forsyth@terzarima.net> wrote:
> >waserror() depends on callee-save.
>
> caller-save, and a few other conventions (or rather, no need for more conventions).
> specifically, it's enough to save the pc and stack. all variables will
> have the right values on non-zero return from setjmp, regardless of the
> presence or absence of "volatile", and that return can be done by
> simply setting the pc and the stack pointer to the values in the jmp_buf.

What exactly is different between these calling conventions ?
How much does the Plan9 code depend on them ?


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] GNU/Linux/Plan 9 disto

[erik quanstrom]

> * Charles Forsyth <forsyth@terzarima.net> wrote:
> > >waserror() depends on callee-save.
> > 
> > caller-save, and a few other conventions (or rather, no need for more conventions).
> > specifically, it's enough to save the pc and stack. all variables will
> > have the right values on non-zero return from setjmp, regardless of the
> > presence or absence of "volatile", and that return can be done by
> > simply setting the pc and the stack pointer to the values in the jmp_buf.
> 
> What exactly is different between these calling conventions ?

http://en.wikipedia.org/wiki/Calling_convention

> How much does the Plan9 code depend on them ?

since you haven't specified a unit with which to measure
this dependency, i'll give it as 1.773 µdirac/tatum·fortnight.
alternatively, i've seen this specified as 6.773 Mlenat·emacs.
(it just looks stupendous when you think of it that way.)

in other words, it's not a deep dependency, but a pervasive
and difficult to dislodge one.  without the convention, waserror()
becomes too subtile and quick to anger to be of any use to
mortal programmers.

- erik

Re: [9fans] GNU/Linux/Plan 9 disto

[Enrico Weigelt]

* Jens Staal <staal1978@gmail.com> wrote:

> Personally, I believe that a Plan9 target for a cross compiler might
> be more interesting. GCC already added support for the Plan9 dialect
> of C. If it also could be made to compile Plan9 binaries, it could be
> used for an alternative self-hosting distro as the one you envisaged.

ACK. If, lets say, crosstool-NG could produce an GCC-alike (not necessarily
GCC itself, but supporting the same command line interfaces) cross-toolchain
for native Plan9 and p9p, that would be a *big* help. Perhaps even extend
the autohell to support it.

On the other hand, we could also port plan9's make to GNU natively.


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] GNU/Linux/Plan 9 disto

[hiro]

> I'd certainly like something where my local processes migrate from my lower powered laptop including the Window manager migrate to a more powerful CPU when it becomes available and back again when my laptop becomes disconnected,

Here network latency is too high for such small tasks nowadays solved by CPUs.
If you have to wait for your CPU in the 21st century you're doing it wrong.

Re: [9fans] GNU/Linux/Plan 9 disto

[erik quanstrom]

On Mon Jul 11 13:58:27 EDT 2011, 23hiro@googlemail.com wrote:
> > I'd certainly like something where my local processes migrate from
> > my lower powered laptop including the Window manager migrate to a
> > more powerful CPU when it becomes available and back again when my
> > laptop becomes disconnected,
> >
> Here network latency is too high for such small tasks nowadays solved
> by CPUs.  If you have to wait for your CPU in the 21st century you're
> doing it wrong.

maybe in this particular case.  here are two others where i think
using more powerful cpus and/or networks might make a lot of sense.
- suppose you have a really low powered device that is sometimes docked.

- suppose you want to run fluid dynamics on your phone.  if you want
to make it run faster, you import some resources from a computing resource
like ec2.

it's true that network latency is a huge deal these days.  and even a multicore
machine looks like a bunch of fast cores connected to their l3 and each other
by a slow network.  but if you have a "large enough" packet of work, it can make
sense to move it over to another cpu.  i don't see why given an apropriate defn
of "large enough" this couldn't work across different orders of magnitude.

- erik

Re: [9fans] GNU/Linux/Plan 9 disto

[hiro]

> it's true that network latency is a huge deal these days.  and even a
> multicore
> machine looks like a bunch of fast cores connected to their l3 and each
> other
> by a slow network.  but if you have a "large enough" packet of work, it can
> make
> sense to move it over to another cpu.  i don't see why given an apropriate
> defn
> of "large enough" this couldn't work across different orders of magnitude.

I agree there are a lot of cases where I still want exactly that. On
plan9 of course I don't pull from sources over my mobile phone,
instead pull and compile on the CPU server. Some sane non-transparent
CPU offloading worth it because of
 1. slow networks and
 2. compilers still running fastest on fast CPUs

My main point is there won't be any space left for CPU offloading when
it gets limited not only by good old network latency, but also the
increasingly powerful GPGPU/APU/FPGA/CPLD/ASIC side.

Correct me if I'm wrong.

Re: [9fans] GNU/Linux/Plan 9 disto

[Ethan Grammatikidis]

On Tue, 12 Jul 2011 02:10:50 +0200
hiro <23hiro@googlemail.com> wrote:

>  2. compilers still running fastest on fast CPUs

I have a quad core I bought specifically for compiling, that was one of the major tasks the box was going to do as I wanted to get more involved in Source Mage GNU/Linux. It performed admirably, but the vast majority of the compiles were IO bound. The IO in question was all to RAM -- the sources were unpacked to tmpfs and the compilation performed there. I used make -j6; 6 jobs, 2 more than the number of cores, and unless it was compiling Firefox or one or two other very large packages, average core utilization would be around 50%.

I don't know if the opinion stated above comes from C++ compiles or from the insane optimization techniques Gcc is sometimes capable of. I choose my words carefully; I mean to use "insane" there because you can increase compilation time dramatically by demanding more optimization from Gcc, and never notice the difference in desktop use. Even given relatively compute-intensive tasks such as compilation, IO limitation is still very significant as my example above shows.

To my mind, the really scary thing about Gcc is that the less heavyweight optimization paths are less well tested. You don't really have a choice about burning up your CPUs on optimization which is worthless for most code. I got lucky; when I bought my quad core Gcc did not yet have specific optimizations for it at all, so I was able to use the generic x86_64 optimization path. I stopped using Source Mage before that generic path had a chance to bit-rot.

There is yet another thing, and now I'm starting to feel ill relating the troubles. Gcc's optimization can be crap for those programs which most require it! Video transformation requires an algorithm which is actually *slowed* by the optimization attempts of Gcc as well as (iirc) Intel's CC. It can be done right, DEC had a compiler which could optimize it well, but video playback software still relies on assembler code because Gcc doesn't do it right. I'm sure video playback is not the only compute-intensive task in which such an algorithm is used. It doesn't stretch my imagination much to see rendering or even perhaps fluid dynamics having such a problem, and we can fall back to assembler with 8c just as easily as with Gcc.

With all these factors, I don't think it's religious at all to say Gcc is one big pile of shit and -- I'm sorry, hiro, -- to wonder at anyone who wants to use it.

Re: [9fans] GNU/Linux/Plan 9 disto

[hiro]

Compiling should be called decompressing ;)

Re: [9fans] GNU/Linux/Plan 9 disto

[Richard Miller]

> On
> plan9 of course I don't pull from sources over my mobile phone,
> instead pull and compile on the CPU server.

Compiling on a phone is no longer so far-fetched.  Compiling all
of plan9port from scratch on a Nokia n900 takes about 1.5 hours.
It seems to be less hassle just to install gcc on the n900 than to
set up Nokia's weird cross-compiling environment on another host.

Re: [9fans] GNU/Linux/Plan 9 disto

[Ethan Grammatikidis]

On Tue, 12 Jul 2011 19:09:44 +0100
Richard Miller <9fans@hamnavoe.com> wrote:

> > On
> > plan9 of course I don't pull from sources over my mobile phone,
> > instead pull and compile on the CPU server.
>
> Compiling on a phone is no longer so far-fetched.  Compiling all
> of plan9port from scratch on a Nokia n900 takes about 1.5 hours.
> It seems to be less hassle just to install gcc on the n900 than to
> set up Nokia's weird cross-compiling environment on another host.

This is exactly what I found on my Zaurus a few years ago... and then I found that the available basesystems were broken for compilation and putting a sane basesystem together was impossible. Glibc was installed, and recompiling that was... well, I never succeeded despite trying very hard and having plenty of time to put into it. Deitlibc didn't even have an arm port when I first wanted one, and ucLibc again wanted to do everything in a confusing alternate environment. It wasn't exactly cross-compilation, it was an environment which ran in QEmu, but anything I built in that QEmu VM wouldn't run on the real hardware, despite static linking. Horrible mess. I never did get to use that Zaurus properly. Hm, I never finished getting p9p to compile, either. I submitted one small patch but it wasn't all that was needed and I lost interest in the Zaurus altogether about a year before p9p was fixed for arm/Linux.