9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: lucio@proxima.alt.za
To: 9fans@9fans.net
Subject: Re: [9fans] MIPS LSB compiler
Date: Sun, 15 Nov 2009 18:52:24 +0200	[thread overview]
Message-ID: <2b8152e044cd233c0ee7603d37f4d369@proxima.alt.za> (raw)
In-Reply-To: <e763acc10911122112t725f030crc94f84f60d8b57d5@mail.gmail.com>

>> Given the addition of this toolchain, one wonders how far we are from
>> being able to port all the P9 compilers to Linux and consequently to
>> all Posix platforms.  My beef is that I have a wide choice of cross-
>> and native toolchains with which to port Plan 9 to a MIPS platform
>> (LSB), but I really wish I could settle on something I am much more
>> comfortable and familiar with.
>
> I guess I'm not following your line of thought here.

There are two almost orthogonal issues here: "go" itself and the
toolchain that it relies on.  Whereas I do care about "go" and would
dearly like to assimilate it into my toolkit, my more immediate
interest lies with porting native Plan 9 "C" facilities beyond the
Plan 9 boundaries, specifically into the various environments served
by the "ELF" object format.  Worse, my wish is for the Plan 9 kernel
to be able to cope with ELF executables so that Plan 9 can readily (*)
join the platforms that can be used to cross-develop software.

Now, the "go" toolchain is very close to the Plan 9 native toolchain,
its most obvious difference lies in its default object format.  Given
the desirability of being able to generate ELF executables from within
Plan 9 (the MIPS toolchain already does, but I had issues with that
before now and the "go" toolchain diverges from that model somewhat, I
believe from inspecting the source somewhat superficially) my hope is
that the differences in the toolchains provided by the "go"
development and Plan 9 can mostly be eliminated.  Besides providing
Plan 9 with a more modern toolchain, it also makes it more practical
to port "go" to Plan 9 and it makes it possible to cross-develop "go"
code on a Plan 9 platform; a small amount of effort in the direction
of the MIPS architecture will also facilitate porting "go" to it.  All
developments I would be keen to contribute to, but lack the confidence
more than the expertise to undertake on my own.

++L

(*) There are mutual benefits: cross-compiling on a GNU platform to a
Plan 9 target is too hard if one needs to produce Plan 9 native
executables.  Dave Hogan managed to twist GCC 3.0 (actually, binutils
2.11, if I remember right) to produce Plan 9 native executables, but I
have failed dismally to reproduce his results on later versions of the
GNU toolchain, it's just too dense for me.  I have configured a
cross-development toolchain under NetBSD that uses the Plan 9
libraries and syscall interface; it isn't yet possible for me to test
whether the generated ELF executable actually would work, too many
other chestnuts in the fire right now.  Were this cross-development
tool to be viable, one would use it to bootstrap the most recent
stable version of GCC/G++, with results some 9fans might welcome.




  parent reply	other threads:[~2009-11-15 16:52 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-13  4:34 lucio
2009-11-13  5:12 ` Roman Shaposhnik
2009-11-13  6:01   ` John Barham
2009-11-13 17:48   ` Tim Newsham
2009-11-13 18:19     ` Iruata Souza
2009-11-13 18:36       ` Tim Newsham
2009-11-15 16:52   ` lucio [this message]
2009-11-15 17:26     ` Paul Lalonde
2009-11-15 22:25       ` ron minnich
2009-11-15 22:43         ` Bruce Ellis
2009-11-16  4:34         ` lucio
2009-11-16 10:11           ` Bruce Ellis
2009-11-16  4:28       ` lucio
2009-11-13 19:41 ` Andre Guenther
2009-11-15 17:55   ` lucio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2b8152e044cd233c0ee7603d37f4d369@proxima.alt.za \
    --to=lucio@proxima.alt.za \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).