From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <13426df10911151425h6a9628b2t9cc321c72c519d15@mail.gmail.com> References: <2b8152e044cd233c0ee7603d37f4d369@proxima.alt.za> <13426df10911151425h6a9628b2t9cc321c72c519d15@mail.gmail.com> Date: Mon, 16 Nov 2009 09:43:32 +1100 Message-ID: <775b8d190911151443h706388edw1b23dbb146eaa47e@mail.gmail.com> From: Bruce Ellis To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Cc: "lucio@proxima.alt.za" Subject: Re: [9fans] MIPS LSB compiler Topicbox-Message-UUID: 9c1a177c-ead5-11e9-9d60-3106f5b1d025 Good work indeed, Ron. All those bits and they all fit together! I guess it also solves the Fortran etc. for Plan9 issue. brucee On 11/16/09, ron minnich wrote: > On Sun, Nov 15, 2009 at 9:26 AM, Paul Lalonde wrote: > > I'd be very interested in an ELF based cross-compilation to plan9. I have > > this many-core IA part that I would desperately love to boot a nicer OS on > > than we currently have (memory footprint, scheduling, vm architecture, > > syscall performance, remote exposure), but the principal application that > > has to run on it is in C++. > > > > If there was a clear path, I might even be able to shake loose some > > resources for it. > > on blue gene I use the IBM toolchain on Linux to produce static elf > binaries. Since the non-Linux kernel on Blue Gene uses the Linux > system call interface, these are in fact just Linux binaries compiled > to the Linux 2.0 system call interface (plus some wacky system call > numbers in the 1024 and up range). I start these Linux/ELF binaries > up on BG/P on Plan 9 using a support program that switches the process > between plan 9 mode and linux mode. The support program on plan 9 uses > libmach to crack the binaries and start them up. I have an in-kernel > linux system call emulation device that lets me run those binaries. I > support a subset of the system calls -- e.g., just enough of futex to > make it go on BG/P -- but extending it is easy. > > I chose the in-kernel support as opposed to existing linuxemu support > on Plan 9 for the usual HPC reason: when you're r unning the app > nothing else should run. > > What's more interesting: I also build Plan 9 binaries on Linux/ELF > that then run under the Linux emulation environment on Plan 9. Why the > emulation environment? Well, the linux toolchain insists on building > in the system calls. So I have a Linux/ELF, that does a few Linux > system calls, that I drectly map to their Plan 9 equivalent > (open/read/write/close -- pretty direct). Since pretty much everything > I need to do on Plan 9 involves those 4, I've really got a native Plan > 9 binary that happens to want to talk Linux system call numbers ... > This way, I can run the *same* binary on Linux and Plan 9, and get > very direct performance comparisons. And, yes, in some cases, Plan 9 > is winning :-) > > Anyway all that code is available. > > ron > >