From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 Date: Wed, 2 Feb 2011 01:56:48 -0500 Message-ID: From: Jacob Todd To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016e6dd89692a68af049b4727f8 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a7c20034-ead6-11e9-9d60-3106f5b1d025 --0016e6dd89692a68af049b4727f8 Content-Type: text/plain; charset=UTF-8 And russ cox, and everyone else in the CONTRIBUTORS file. On Feb 2, 2011 12:39 AM, "Scott Sullivan" wrote: --0016e6dd89692a68af049b4727f8 Content-Type: text/html; charset=UTF-8

And russ cox, and everyone else in the CONTRIBUTORS file.

On Feb 2, 2011 12:39 AM, "Scott Sullivan" <scott@ss.org> wrote:
--0016e6dd89692a68af049b4727f8-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 1 Feb 2011 23:06:33 -0800 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a7cbda6e-ead6-11e9-9d60-3106f5b1d025 Actually, I think we've talked quite enough at this point, perhaps it's time to take a break and let's see some concrete work. Where's the mkfile that broke your .h? What do your macros look like? What are you going to do? I'll retire from the thread now. Just remember, Smiley, it's a good idea not to come across too much like a missionary bringing knowledge to the ignorant heathens -- which is certainly a bit of the tone of your notes. Missionaries, at least according to the cartoons, sometimes are invited to dinner, and other times are invited to BE dinner. :-) So, let's see it. ron From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Tue, 01 Feb 2011 23:06:33 PST." References: From: Bakul Shah Date: Tue, 1 Feb 2011 23:25:06 -0800 Message-Id: <20110202072506.95A375B8A@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a7d40a72-ead6-11e9-9d60-3106f5b1d025 On Tue, 01 Feb 2011 23:06:33 PST ron minnich wrote: > > Just remember, Smiley, it's a good idea not to come across too much > like a missionary bringing knowledge to the ignorant heathens -- which > is certainly a bit of the tone of your notes. Missionaries, at least > according to the cartoons, sometimes are invited to dinner, and other > times are invited to BE dinner. :-) More Smiley (as played by Alec Guinness) and less Bond? From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 2 Feb 2011 09:25:45 +0200 From: Lucio De Re To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20110202072545.GA3176@fangle.proxima.alt.za> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a7dac024-ead6-11e9-9d60-3106f5b1d025 On Tue, Feb 01, 2011 at 11:06:33PM -0800, ron minnich wrote: > Missionaries, at least > according to the cartoons, sometimes are invited to dinner, and other > times are invited to BE dinner. :-) > And they often are fatter than sacred cows :-) ++L From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 2 Feb 2011 02:35:21 -0500 Message-ID: From: Nick LaForge To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a7e154fc-ead6-11e9-9d60-3106f5b1d025 I hope it won't seem rude to suggest it, but the go-nuts list is the optimum place for your specific concerns. The Go authors read it and are very conscientious in responding to serious questions. The Go authors did express confidence that GC performance could eventually be made competitive, although I couldn't tell you whether that has yet happened. I would nevertheless keep in mind that they are experienced professionals (c.f. Inferno) and that you'd be wrong to malign GC categorically based on your experiences with the proliferation of various toy languages on the net. (I won't mention names.) If you want a modern C++ or some other heavyweight language on Plan 9, I'll point out that there was some talk in August about a LLVM port, though you'll be hard pressed to find many here that desire it above Go. Nick On 2/2/11, Jacob Todd wrote: > And russ cox, and everyone else in the CONTRIBUTORS file. > On Feb 2, 2011 12:39 AM, "Scott Sullivan" wrote: > From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 2 Feb 2011 09:45:56 -0800 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0016e642d67e994ce2049b5038f6 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a8274bba-ead6-11e9-9d60-3106f5b1d025 --0016e642d67e994ce2049b5038f6 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Feb 1, 2011 at 11:35 PM, Nick LaForge wrote: > I hope it won't seem rude to suggest it, but the go-nuts list is the > optimum place for your specific concerns. The Go authors read it and > are very conscientious in responding to serious questions. > > The Go authors did express confidence that GC performance could > eventually be made competitive, although I couldn't tell you whether > that has yet happened. I would nevertheless keep in mind that they > are experienced professionals (c.f. Inferno) and that you'd be wrong > to malign GC categorically based on your experiences with the > proliferation of various toy languages on the net. (I won't mention > names.) > > If you want a modern C++ or some other heavyweight language on Plan 9, > I'll point out that there was some talk in August about a LLVM port, > though you'll be hard pressed to find many here that desire it above > Go. > Well if I were funded and had an infinite amount of time I'd think LLVM for Plan 9 would be excellent, as well as Go on LLVM :-). > > Nick > > On 2/2/11, Jacob Todd wrote: > > And russ cox, and everyone else in the CONTRIBUTORS file. > > On Feb 2, 2011 12:39 AM, "Scott Sullivan" wrote: > > > > --0016e642d67e994ce2049b5038f6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Feb 1, 2011 at 11:35 PM, Nick La= Forge <nickla= forge@gmail.com> wrote:
I hope it won't seem rude to suggest it, but the go-nuts list is the optimum place for your specific concerns. =A0The Go authors read it and
are very conscientious in responding to serious questions.

The Go authors did express confidence that GC performance could
eventually be made competitive, although I couldn't tell you whether that has yet happened. =A0I would nevertheless keep in mind that they
are experienced professionals (c.f. Inferno) and that you'd be wrong to malign GC categorically based on your experiences with the
proliferation of various toy languages on the net. =A0(I won't mention<= br> names.)

If you want a modern C++ or some other heavyweight language on Plan 9,
I'll point out that there was some talk in August about a LLVM port, though you'll be hard pressed to find many here that desire it above Go.

Well if I were funded and had an in= finite amount of time I'd think LLVM for Plan 9 would be excellent, as = well as Go on LLVM :-).
=A0

Nick

On 2/2/11, Jacob Todd <jaketodd= 422@gmail.com> wrote:
> And russ cox, and everyone else in the CONTRIBUTORS file.
> On Feb 2, 2011 12:39 AM, "Scott Sullivan" <scott@ss.org> wrote:
>


--0016e642d67e994ce2049b5038f6-- From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Wed, 02 Feb 2011 09:45:56 PST." References: From: Bakul Shah Date: Wed, 2 Feb 2011 11:19:24 -0800 Message-Id: <20110202191924.5AD2E5B3B@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a8b6356e-ead6-11e9-9d60-3106f5b1d025 On Wed, 02 Feb 2011 09:45:56 PST David Leimbach wrote: > > Well if I were funded and had an infinite amount of time I'd think LLVM for > Plan 9 would be excellent, as well as Go on LLVM :-). llvm port would need c++. $ size /usr/local/bin/clang text data bss dec hex filename 22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang 1.2+ Million LOC in **/*.cpp **/*.h (though this includes tests etc.) Even gcc is smaller now! It boggles my mind they chose C++ instead of one of Scheme, Ocaml, Haskell or CL. Then there is libfirm (in C) which uses Cliff Click's ideas of a low level graph based intermediate representation. Seemed quite promising when I looked at it (a couple of years ago). It is much smaller than llvm (where they can be compared). But looks like most of funding oxygen has been going to llvm. http://pp.info.uni-karlsruhe.de/firm/Main_Page From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 2 Feb 2011 19:21:43 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <9d3ce7e9b47edddf2f233bc5bd5112c2@terzarima.net> References: <9d3ce7e9b47edddf2f233bc5bd5112c2@terzarima.net> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a8fd7b5e-ead6-11e9-9d60-3106f5b1d025 On Wed Feb 2 19:19:13 EST 2011, forsyth@terzarima.net wrote: > >$ size /usr/local/bin/clang > > text data bss dec hex filename > >22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang > > impressive. certainly in the sense of `makes quite a dent if dropped'. and quite a clang. i worked on a project that big ... a 35yo 3d cad system. and to be fair to the cad system, most of its bulk was static tables. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <9d3ce7e9b47edddf2f233bc5bd5112c2@terzarima.net> From: Charles Forsyth Date: Thu, 3 Feb 2011 00:30:15 +0000 To: 9fans@9fans.net In-Reply-To: <20110202191924.5AD2E5B3B@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a8ed2830-ead6-11e9-9d60-3106f5b1d025 >$ size /usr/local/bin/clang > text data bss dec hex filename >22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang impressive. certainly in the sense of `makes quite a dent if dropped'. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> Date: Wed, 2 Feb 2011 16:50:48 -0800 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a90aa7b6-ead6-11e9-9d60-3106f5b1d025 On Wed, Feb 2, 2011 at 4:52 PM, Charles Forsyth wrote: > i suppose a more useful comment might be a question: > how does a C compiler get to be that big? what is all that code doing? iterators, string objects, and a full set of C macros that ensure boundary conditions and improve interfaces. ron From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> From: Charles Forsyth Date: Thu, 3 Feb 2011 00:52:35 +0000 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a90407d0-ead6-11e9-9d60-3106f5b1d025 > >$ size /usr/local/bin/clang > > text data bss dec hex filename > >22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang i suppose a more useful comment might be a question: how does a C compiler get to be that big? what is all that code doing? From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Thu, 03 Feb 2011 00:52:35 GMT." <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> From: Bakul Shah Date: Wed, 2 Feb 2011 18:16:07 -0800 Message-Id: <20110203021608.006575B67@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a910b70a-ead6-11e9-9d60-3106f5b1d025 On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth wrote: > > >$ size /usr/local/bin/clang > > > text data bss dec hex filename > > >22842862 1023204 69200 23935266 16d3922 /usr/local/bin/clang > > i suppose a more useful comment might be a question: > how does a C compiler get to be that big? what is all that code doing? It is a C/C++/Obj-C compiler & does static analysis, has backends for multiple processor types as well as C as a target, a lot of optimization tricks etc. See llvm.org. But frankly, I think they have lost the plot. C is basically a portable assembly programming language & in my highly biased opinion a C compiler should do no more than peephole optimizations. If you want more, might as well use a high level language. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20110203021608.006575B67@mail.bitblocks.com> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> Date: Wed, 2 Feb 2011 18:25:30 -0800 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001636ed6965c263b4049b577a66 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a91a52ba-ead6-11e9-9d60-3106f5b1d025 --001636ed6965c263b4049b577a66 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 2, 2011 at 6:16 PM, Bakul Shah > wrote: > On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth > wrote: > > > >$ size /usr/local/bin/clang > > > > text data bss dec hex filename > > > >22842862 1023204 69200 23935266 16d3922 > /usr/local/bin/clang > > > > i suppose a more useful comment might be a question: > > how does a C compiler get to be that big? what is all that code doing? > > It is a C/C++/Obj-C compiler & does static analysis, has > backends for multiple processor types as well as C as a > target, a lot of optimization tricks etc. See llvm.org. But > frankly, I think they have lost the plot. C is basically a > portable assembly programming language & in my highly biased > opinion a C compiler should do no more than peephole > optimizations. If you want more, might as well use a high > level language. > > Don't forget objective-c++ :-). http://clang.llvm.org/features.html#simplecode has some interesting pictures and words --001636ed6965c263b4049b577a66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Feb 2, 2011 at 6:16 PM, Bakul Sh= ah <bak= ul+plan9@bitblocks.com> wrote:
It is a C/C++/Obj-C compiler & does static analysis, has backends for multiple processor types as well as C as a
target, a lot of optimization tricks etc. =A0See llvm.org. =A0But
frankly, I think they have lost the plot. C is basically a
portable assembly programming language & in my highly biased
opinion a C compiler should do no more than peephole
optimizations. =A0If you want more, might as well use a high
level language.


Don't forget objective-c++ :-). =A0

http://clang.llvm.org/features.html#simplecode has some interesting p= ictures and words
--001636ed6965c263b4049b577a66-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Wed, 2 Feb 2011 21:26:27 -0500 To: 9fans@9fans.net Message-ID: <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> In-Reply-To: <20110203021608.006575B67@mail.bitblocks.com> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a92408b4-ead6-11e9-9d60-3106f5b1d025 > It is a C/C++/Obj-C compiler & does static analysis, has > backends for multiple processor types as well as C as a > target, a lot of optimization tricks etc. See llvm.org. But > frankly, I think they have lost the plot. C is basically a > portable assembly programming language & in my highly biased > opinion a C compiler should do no more than peephole > optimizations. If you want more, might as well use a high > level language. preach it, brother. i couldn't agree more. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3cfdf1cf87e3565034a4e2d714474b18@terzarima.net> From: Charles Forsyth Date: Thu, 3 Feb 2011 08:35:53 +0000 To: 9fans@9fans.net In-Reply-To: <20110203021608.006575B67@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a9ca981e-ead6-11e9-9d60-3106f5b1d025 >It is a C/C++/Obj-C compiler & does static analysis, has >backends for multiple processor types as well as C as a >target, a lot of optimization tricks etc. 22mbytes is still a lot of "etc.". i've no objection to optimisations big and small, but that still wouldn't explain the size (to me). FORTRAN H Enhanced did so much with so little! if they combine every language and every target into one executable -- a "busybox" for compilers i suppose -- that might plump it up, but even then ... seriously, i'm just astounded. From mboxrd@z Thu Jan 1 00:00:00 1970 To: <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 3 Feb 2011 02:56:18 -0600 From: EBo In-Reply-To: <3cfdf1cf87e3565034a4e2d714474b18@terzarima.net> References: <3cfdf1cf87e3565034a4e2d714474b18@terzarima.net> Message-ID: <2627143a8d8f77fd931db713a1ac1949@swcp.com> User-Agent: RoundCube Webmail/0.4-trunk Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a9d1399e-ead6-11e9-9d60-3106f5b1d025 On Thu, 3 Feb 2011 08:35:53 +0000, Charles Forsyth wrote: >>It is a C/C++/Obj-C compiler & does static analysis, has >>backends for multiple processor types as well as C as a >>target, a lot of optimization tricks etc. > > ... FORTRAN H Enhanced did so much with so little! ... Is there a compiler that does FORTRAN compiler for Plan 9? Or have I lost track of the thread? EBo -- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <38899c887189359a27e790996ae92c00@terzarima.net> From: Charles Forsyth Date: Thu, 3 Feb 2011 09:46:00 +0000 To: 9fans@9fans.net In-Reply-To: <2627143a8d8f77fd931db713a1ac1949@swcp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a9d7e2a8-ead6-11e9-9d60-3106f5b1d025 FORTRAN H Enhanced was an early optimising compiler. FORTRAN H for System/360, then FORTRAN H Extended for System/370; FORTRAN H Enhanced added further insight to get better code. From mboxrd@z Thu Jan 1 00:00:00 1970 To: <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 3 Feb 2011 03:47:17 -0600 From: EBo In-Reply-To: <38899c887189359a27e790996ae92c00@terzarima.net> References: <38899c887189359a27e790996ae92c00@terzarima.net> Message-ID: <78c41896424e345485cd1d783502fd9e@swcp.com> User-Agent: RoundCube Webmail/0.4-trunk Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a9f44574-ead6-11e9-9d60-3106f5b1d025 On Thu, 3 Feb 2011 09:46:00 +0000, Charles Forsyth wrote: > FORTRAN H Enhanced was an early optimising compiler. > > FORTRAN H for System/360, then FORTRAN H Extended for System/370; > FORTRAN H Enhanced added further insight to get better code. Ah. Thanks for the info. I asked because some of the physicists and atmospheric scientists I work with are likely to insist on having FORTRAN. I still have not figured how I will deal with that if at all. EBo -- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 3 Feb 2011 11:50:27 +0200 From: Lucio De Re To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20110203095027.GI1866@fangle.proxima.alt.za> References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <78c41896424e345485cd1d783502fd9e@swcp.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: a9fa3b82-ead6-11e9-9d60-3106f5b1d025 On Thu, Feb 03, 2011 at 03:47:17AM -0600, EBo wrote: > > Ah. Thanks for the info. I asked because some of the physicists and > atmospheric scientists I work with are likely to insist on having > FORTRAN. I still have not figured how I will deal with that if at > all. > If the cost can be met, porting GCC 3.0 (the Hogan efforts) and the Fortran front end may be feasible. You may even be able to rope me into helping, but that is hardly a recommendation :-) ++L From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: C H Forsyth Date: Thu, 3 Feb 2011 10:38:30 +0000 To: 9fans@9fans.net In-Reply-To: <78c41896424e345485cd1d783502fd9e@swcp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: aa225856-ead6-11e9-9d60-3106f5b1d025 > Ah. Thanks for the info. I asked because some of the physicists and > atmospheric scientists I work with are likely to insist on having > FORTRAN. I still have not figured how I will deal with that if at all. it's not just the FORTRAN but supporting libraries, sometimes large ones, including ones in C++, are often required as well. i'd concluded that cross-compilation was currently the only effective route. i hadn't investigated whether something like linuxemu could be used (or extended easily enough) to allow cross-compilation within the plan 9 environment. i have found a few exceptions written in plain, reasonably portable C, good for my purposes, but not characteristic of scientific applications in general. From mboxrd@z Thu Jan 1 00:00:00 1970 To: <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 3 Feb 2011 06:07:33 -0600 From: EBo In-Reply-To: References: Message-ID: <8f46b210f655183b56d52e5737ace865@swcp.com> User-Agent: RoundCube Webmail/0.4-trunk Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: aa57326a-ead6-11e9-9d60-3106f5b1d025 On Thu, 3 Feb 2011 10:38:30 +0000, C H Forsyth wrote: > it's not just the FORTRAN but supporting libraries, sometimes large > ones, > including ones in C++, are often required as well. i'd concluded that > cross-compilation was currently the only effective route. > i hadn't investigated whether something like linuxemu could be > used (or extended easily enough) to allow cross-compilation within > the plan 9 environment. > > i have found a few exceptions written in plain, reasonably portable > C, good for my purposes, > but not characteristic of scientific applications in general. Agreed, and then there is the Netlib Java numerical analysis code -- That one gave be indigestion... One of the biggest problems is that no one wants rewrite linpack, blas, etc., not that it has been polished within an inch of the developers lives. As for FORTRAN, I thought about looking into the old f2c, and see how that worked for getting some FORTRAN compiled in Plan 9 as a demonstration. I'll think about linuxemu in this context. EBo -- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> Date: Thu, 3 Feb 2011 07:08:57 -0800 Message-ID: From: David Leimbach To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: aadec1ee-ead6-11e9-9d60-3106f5b1d025 On Wednesday, February 2, 2011, erik quanstrom wrot= e: >> It is a C/C++/Obj-C compiler & does static analysis, has >> backends for multiple processor types as well as C as a >> target, a lot of optimization tricks etc. =A0See llvm.org. =A0But >> frankly, I think they have lost the plot. C is basically a >> portable assembly programming language & in my highly biased >> opinion a C compiler should do no more than peephole >> optimizations. =A0If you want more, might as well use a high >> level language. > > preach it, brother. =A0i couldn't agree more. > > - erik > > Well LLVM uses its internal ASTs for a lot of the optimizations doesnt it? My understanding is LLVM is a stack of software that you compose other programming language tools by including the libraries you want. One might be able to remove the optimizing behaviors one doesn't want pretty easily, or write one's own optimizing layer that's stripped down. Then one could have the "do what I said" compiler instead of the "do what you think I meant" one. I believe there are occasions for each type of compiler really. It might seem really big and bloated but I still think what they've done is kind of neat. Making a real compiler in Haskell or O'Caml is pretty damned easy with LLVM bindings. I wonder how difficult it is to target Plan 9 with LLVM. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> Date: Thu, 3 Feb 2011 18:19:05 +0200 Message-ID: From: Eugene Gorodinsky To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=000e0cd37c0cdd8a39049b631f27 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: aae65a76-ead6-11e9-9d60-3106f5b1d025 --000e0cd37c0cdd8a39049b631f27 Content-Type: text/plain; charset=UTF-8 To be fair, gcc, g++ and gobjc combined are actually bigger than clang+llvm. At least on my system. So it could have been worse. 2011/2/3 David Leimbach > On Wednesday, February 2, 2011, erik quanstrom > wrote: > >> It is a C/C++/Obj-C compiler & does static analysis, has > >> backends for multiple processor types as well as C as a > >> target, a lot of optimization tricks etc. See llvm.org. But > >> frankly, I think they have lost the plot. C is basically a > >> portable assembly programming language & in my highly biased > >> opinion a C compiler should do no more than peephole > >> optimizations. If you want more, might as well use a high > >> level language. > > > > preach it, brother. i couldn't agree more. > > > > - erik > > > > > Well LLVM uses its internal ASTs for a lot of the optimizations doesnt > it? My understanding is LLVM is a stack of software that you compose > other programming language tools by including the libraries you want. > One might be able to remove the optimizing behaviors one doesn't want > pretty easily, or write one's own optimizing layer that's stripped > down. Then one could have the "do what I said" compiler instead of > the "do what you think I meant" one. > > I believe there are occasions for each type of compiler really. > > It might seem really big and bloated but I still think what they've > done is kind of neat. Making a real compiler in Haskell or O'Caml is > pretty damned easy with LLVM bindings. > > I wonder how difficult it is to target Plan 9 with LLVM. > > --000e0cd37c0cdd8a39049b631f27 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable To be fair, gcc, g++ and gobjc combined are actually bigger than clang+llvm= . At least on my system. So it could have been worse.

2011/2/3 David Leimbach <leimy2k@gmail.com>
On Wednesday, February 2,= 2011, erik quanstrom <quanstro= @quanstro.net> wrote:
>> It is a C/C++/Obj-C compil= er & does static analysis, has
>> backends for multiple processor types as well as C as a
>> target, a lot of optimization tricks etc. =C2=A0See llvm.org. =C2=A0But
>> frankly, I think they have lost the plot. C is basically a
>> portable assembly programming language & in my highly biased >> opinion a C compiler should do no more than peephole
>> optimizations. =C2=A0If you want more, might as well use a high >> level language.
>
> preach it, brother. =C2=A0i couldn't agree more.
>
> - erik
>
>
Well LLVM uses its internal ASTs for a lot of the optimizations= doesnt
it? =C2=A0My understanding is LLVM is a stack of software that you compose<= br> other programming language tools by including the libraries you want.
One might be able to remove the optimizing behaviors one doesn't want pretty easily, or write one's own optimizing layer that's stripped<= br> down. =C2=A0Then one could have the "do what I said" compiler ins= tead of
the "do what you think I meant" one.

I believe there are occasions for each type of compiler really.

It might seem really big and bloated but I still think what they've
done is kind of neat. =C2=A0Making a real compiler in Haskell or O'Caml= is
pretty damned easy with LLVM bindings.

I wonder how difficult it is to target Plan 9 with LLVM.


--000e0cd37c0cdd8a39049b631f27-- From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Thu, 03 Feb 2011 07:08:57 PST." References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> From: Bakul Shah Date: Thu, 3 Feb 2011 09:41:29 -0800 Message-Id: <20110203174129.C984D5B91@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: aaf8fe88-ead6-11e9-9d60-3106f5b1d025 On Thu, 03 Feb 2011 07:08:57 PST David Leimbach wrote: > On Wednesday, February 2, 2011, erik quanstrom wrote: > >> It is a C/C++/Obj-C compiler & does static analysis, has > >> backends for multiple processor types as well as C as a > >> target, a lot of optimization tricks etc. See llvm.org. But > >> frankly, I think they have lost the plot. C is basically a > >> portable assembly programming language & in my highly biased > >> opinion a C compiler should do no more than peephole > >> optimizations. If you want more, might as well use a high > >> level language. > > > > preach it, brother. i couldn't agree more. > > > > - erik > > > > > Well LLVM uses its internal ASTs for a lot of the optimizations doesnt > it? My understanding is LLVM is a stack of software that you compose > other programming language tools by including the libraries you want. > One might be able to remove the optimizing behaviors one doesn't want > pretty easily, or write one's own optimizing layer that's stripped > down. Then one could have the "do what I said" compiler instead of > the "do what you think I meant" one. I agree with their goal but not its execution. I think a toolkit for manipulating graph based program representations to build optimizing compilers is a great idea but did they do it in C++? Consider what `stalin' does in about 3300 lines of Scheme code. It translates R4RS scheme to C and takes a lot of time doing so but the code is generates is blazingly fast. The kind of globally optimized C code you or I wouldn't have the patience to write. Or the ability to keep all that context in one's head to do as good a job. Stalin compiles itself to over 660K lines of C code! Then you give this C code to gcc and it munches away for many minutes and finally dies on a 2GB system! If gcc was capable of only doing peephole optimizing, it would've been able to generate code much more quickly and without need gigabytes of memory. Given funding and a lot of free time it would make more sense to build a language agnostic optimizing toolkit by learning & stealing concepts/code from Stalin. Ideally: < src src-to-graph | optimizer | graph-to-C | cc > obj Where pipes are two way. > I believe there are occasions for each type of compiler really. Yes. > It might seem really big and bloated but I still think what they've > done is kind of neat. Making a real compiler in Haskell or O'Caml is > pretty damned easy with LLVM bindings. > > I wonder how difficult it is to target Plan 9 with LLVM. From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 3 Feb 2011 13:11:07 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <20110203174129.C984D5B91@mail.bitblocks.com> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> <20110203174129.C984D5B91@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: aaff21d2-ead6-11e9-9d60-3106f5b1d025 > I agree with their goal but not its execution. I think a > toolkit for manipulating graph based program representations > to build optimizing compilers is a great idea but did they > do it in C++? are you sure that the problem isn't the graph representation? gcc also takes a graph-based approach. abstraction isn't free. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 From: smiley@zenzebra.mv.com To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> Date: Thu, 3 Feb 2011 18:21:28 +0000 In-Reply-To: <78c41896424e345485cd1d783502fd9e@swcp.com> (ebo@sandien.com's message of "Thu, 03 Feb 2011 03:47:17 -0600") Message-ID: <86ei7pkmhj.fsf@cmarib.ramside> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: ab062b1c-ead6-11e9-9d60-3106f5b1d025 EBo writes: > Ah. Thanks for the info. I asked because some of the physicists and > atmospheric scientists I work with are likely to insist on having > FORTRAN. I still have not figured how I will deal with that if at > all. I thought those folks used languages like Matlab & Mathematica for analysis, modeling, etc. At least those were what we used in the physics department @ RPI. -- +---------------------------------------------------------------+ |E-Mail: smiley@zenzebra.mv.com PGP key ID: BC549F8B| |Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A BC54 9F8B| +---------------------------------------------------------------+ From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20110203174129.C984D5B91@mail.bitblocks.com> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> <20110203174129.C984D5B91@mail.bitblocks.com> Date: Thu, 3 Feb 2011 13:29:22 -0500 Message-ID: From: Joseph Stewart To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=0015174c1328c7e59a049b64f1b9 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: ab15b884-ead6-11e9-9d60-3106f5b1d025 --0015174c1328c7e59a049b64f1b9 Content-Type: text/plain; charset=ISO-8859-1 Consider what `stalin' does in about 3300 lines of Scheme > code. It translates R4RS scheme to C and takes a lot of time > doing so but the code is generates is blazingly fast. The > kind of globally optimized C code you or I wouldn't have the > patience to write. Or the ability to keep all that context in > one's head to do as good a job. Stalin compiles itself to > over 660K lines of C code! Then you give this C code to gcc > and it munches away for many minutes and finally dies on a > 2GB system! If gcc was capable of only doing peephole > optimizing, it would've been able to generate code much more > quickly and without need gigabytes of memory. > Ha! Just tried to compile Stalin on my 4G laptop... it quickly became a laptop fryer... OUCH! I might try 6c or 8c in a bit for comparison. -joe --0015174c1328c7e59a049b64f1b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Conside= r what `stalin' does in about 3300 lines of Scheme
code. It translates R4RS scheme to C and takes a lot of time
doing so but the code is generates is blazingly fast. The
kind of globally optimized C code you or I wouldn't have the
patience to write. Or the ability to keep all that context in
one's head to do as good a job. Stalin compiles itself to
over 660K lines of C code! Then you give this C code to gcc
and it munches away for many minutes and finally dies on a
2GB system! If gcc was capable of only doing peephole
optimizing, it would've been able to generate code much more
quickly and without need gigabytes of memory.

Ha! Just tried to compile Stalin on my 4G laptop... it quickly becam= e a laptop fryer... OUCH!

I might try 6c or 8c in = a bit for comparison.

-joe=A0
--0015174c1328c7e59a049b64f1b9-- From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Thu, 03 Feb 2011 13:11:07 EST." References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> <20110203174129.C984D5B91@mail.bitblocks.com> From: Bakul Shah Date: Thu, 3 Feb 2011 10:33:04 -0800 Message-Id: <20110203183304.648355B91@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: ab1c1062-ead6-11e9-9d60-3106f5b1d025 On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom wrote: > > I agree with their goal but not its execution. I think a > > toolkit for manipulating graph based program representations > > to build optimizing compilers is a great idea but did they > > do it in C++? > > are you sure that the problem isn't the graph representation? > gcc also takes a graph-based approach. What problem? All programs are graphs in any case. Optimizations in effect replace one subgraph with another that has better properties. Global optimizers need to keep many more graphs in memory. But you can take short cuts when not optimizing -- if you know a graph is not going to change under you, you can generate code incrementally and may not even need to keep all subgraphs in memory. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <86ei7pkmhj.fsf@cmarib.ramside> References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> <86ei7pkmhj.fsf@cmarib.ramside> Date: Thu, 3 Feb 2011 10:50:24 -0800 Message-ID: From: John Floren To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: ab2e529a-ead6-11e9-9d60-3106f5b1d025 On Thu, Feb 3, 2011 at 10:21 AM, wrote: > EBo writes: > >> Ah. Thanks for the info. =A0I asked because some of the physicists and >> atmospheric scientists I work with are likely to insist on having >> FORTRAN. =A0I still have not figured how I will deal with that if at >> all. > > I thought those folks used languages like Matlab & Mathematica for > analysis, modeling, etc. =A0At least those were what we used in the > physics department @ RPI. > Matlab and Mathematica are great for quick stuff (loved Matlab for my engineering courses) but parallel scientific computing still loves its FORTRAN + MPI + LAPACK etc. The reason being that Matlab is extremely easy to write... but is also slow, and limited to one machine. FORTRAN is extremely primitive, but scientists like it because 1. It's simple (no pesky lambdas etc), 2. They're familiar with it, and 3. It's very efficient. For similar reasons, C + MPI is also quite popular. John From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 3 Feb 2011 13:54:05 -0500 To: 9fans@9fans.net Message-ID: <05360a88f7a0cd797278d6bd6a3ae73f@ladd.quanstro.net> In-Reply-To: <20110203183304.648355B91@mail.bitblocks.com> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> <20110203174129.C984D5B91@mail.bitblocks.com> <20110203183304.648355B91@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: ab3763d0-ead6-11e9-9d60-3106f5b1d025 On Thu Feb 3 13:33:52 EST 2011, bakul+plan9@bitblocks.com wrote: > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom wrote: > > > I agree with their goal but not its execution. I think a > > > toolkit for manipulating graph based program representations > > > to build optimizing compilers is a great idea but did they > > > do it in C++? > > > > are you sure that the problem isn't the graph representation? > > gcc also takes a graph-based approach. > > What problem? the problem you yourself mentioned. gcc/llvm/etc have seem to have produced monsterously huge piles of code, out of all proportion to the problem at hand. i believe you're putting forth the theory that llvm is huge because it's c++. and i'm not so sure. > All programs are graphs in any case. Optimizations in effect > replace one subgraph with another that has better properties. > Global optimizers need to keep many more graphs in memory. > But you can take short cuts when not optimizing -- if you > know a graph is not going to change under you, you can > generate code incrementally and may not even need to keep all > subgraphs in memory. all programs are graphs implies that we should represent them as graphs? maybe all programs ar markov chains, too. ?c and ?a seem to get by fine using pseudoassembler instead of a graph. they are also quite a bit faster and smaller than their graph-based counterparts. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 To: <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 3 Feb 2011 13:09:23 -0600 From: EBo In-Reply-To: <86ei7pkmhj.fsf@cmarib.ramside> References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> <86ei7pkmhj.fsf@cmarib.ramside> Message-ID: <61b63bb81109d1b731fd899e371d271a@swcp.com> User-Agent: RoundCube Webmail/0.4-trunk Subject: [9fans] FORTRAN and tools [was: Modern development language for Plan 9 Topicbox-Message-UUID: ab3f505e-ead6-11e9-9d60-3106f5b1d025 On Thu, 03 Feb 2011 18:21:28 +0000, smiley@zenzebra.mv.com wrote: >> Ah. Thanks for the info. I asked because some of the physicists and >> atmospheric scientists I work with are likely to insist on having >> FORTRAN. I still have not figured how I will deal with that if at >> all. > > I thought those folks used languages like Matlab & Mathematica for > analysis, modeling, etc. At least those were what we used in the > physics department @ RPI. Some of the scientists use those tools, but I am looking first at the primary models like WRF , CMAQ , etc., These are all written in FORTRAN 90/95/RatFOR, but some of the underlying tools are written in C/C++, but only a few. If you can show me a Matlab Global Circulation Model (even for a single cell, but which accounts for the vertical profile and pressure) I'll arrange to buy you a beer or your favorite beverage. I know of some of the energy budget models and similar things, but I would prefer to port something to HPD9 that is a little more substantial. I want to couple various other models like plant growth and survivorship, economics, etc. EBo -- From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Thu, 03 Feb 2011 13:54:05 EST." <05360a88f7a0cd797278d6bd6a3ae73f@ladd.quanstro.net> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> <20110203174129.C984D5B91@mail.bitblocks.com> <20110203183304.648355B91@mail.bitblocks.com> <05360a88f7a0cd797278d6bd6a3ae73f@ladd.quanstro.net> From: Bakul Shah Date: Thu, 3 Feb 2011 11:40:58 -0800 Message-Id: <20110203194058.8F4B55B91@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: abb9c6f4-ead6-11e9-9d60-3106f5b1d025 On Thu, 03 Feb 2011 13:54:05 EST erik quanstrom wrote: > On Thu Feb 3 13:33:52 EST 2011, bakul+plan9@bitblocks.com wrote: > > On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom wr > ote: > > > > I agree with their goal but not its execution. I think a > > > > toolkit for manipulating graph based program representations > > > > to build optimizing compilers is a great idea but did they > > > > do it in C++? > > > > > > are you sure that the problem isn't the graph representation? > > > gcc also takes a graph-based approach. > > > > What problem? > > the problem you yourself mentioned. gcc/llvm/etc have seem > to have produced monsterously huge piles of code, out of all > proportion to the problem at hand. > > i believe you're putting forth the theory that llvm is huge > because it's c++. and i'm not so sure. I must also say llvm has a lot of functionality. But even so there is a lot of bloat. Let me just say the bloat is due to many factors but it has far *less* to do with graphs. Download llvm and take a peek. I think the chosen language and the habits it promotes and the "impedance match" with the problem domain does play a significant role. At any rate, a graph representation would have `data' bloat if any, but not so much code bloat! > > All programs are graphs in any case. Optimizations in effect > > replace one subgraph with another that has better properties. > > Global optimizers need to keep many more graphs in memory. > > But you can take short cuts when not optimizing -- if you > > know a graph is not going to change under you, you can > > generate code incrementally and may not even need to keep all > > subgraphs in memory. > > all programs are graphs implies that we should represent them > as graphs? Or something equivalent. Example: How do you know moving an expression out of a for loop is valid? The optimizer needs to understand the control flow. The _model_ is graph based. But if you look at c/c++ code, typically the "graphiness" is hidden in a mess of ptrs. Which makes equivalent xforms on the representation harder. > seem to get by fine using pseudoassembler instead of a graph. > they are also quite a bit faster and smaller than their graph-based > counterparts. From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 3 Feb 2011 15:33:57 -0500 To: 9fans@9fans.net Message-ID: <7c9185b80ba40fd32ba3aa75bdcc8fcf@ladd.quanstro.net> In-Reply-To: <20110203194058.8F4B55B91@mail.bitblocks.com> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> <20110203174129.C984D5B91@mail.bitblocks.com> <20110203183304.648355B91@mail.bitblocks.com> <05360a88f7a0cd797278d6bd6a3ae73f@ladd.quanstro.net> <20110203194058.8F4B55B91@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: abbfe8d6-ead6-11e9-9d60-3106f5b1d025 > I must also say llvm has a lot of functionality. But even so > there is a lot of bloat. Let me just say the bloat is due to > many factors but it has far *less* to do with graphs. > Download llvm and take a peek. I think the chosen language > and the habits it promotes and the "impedance match" with the > problem domain does play a significant role. do you know of a compiler that uses a graph-based approach that isn't huge? > Or something equivalent. Example: How do you know moving an > expression out of a for loop is valid? The optimizer needs to > understand the control flow. is this still a useful thing to be doing? - erik From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <8f46b210f655183b56d52e5737ace865@swcp.com> References: <8f46b210f655183b56d52e5737ace865@swcp.com> Date: Thu, 3 Feb 2011 17:49:52 -0300 Message-ID: From: "Federico G. Benavento" To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: abc62354-ead6-11e9-9d60-3106f5b1d025 I don't know if f2c meets your needs, but it has always worked. On Thu, Feb 3, 2011 at 9:07 AM, EBo wrote: > On Thu, 3 Feb 2011 10:38:30 +0000, C H Forsyth wrote: >> >> it's not just the FORTRAN but supporting libraries, sometimes large ones= , >> including ones in C++, are often required as well. i'd concluded that >> cross-compilation was currently the only effective route. >> i hadn't investigated whether something like linuxemu could be >> used (or extended easily enough) to allow cross-compilation within >> the plan 9 environment. >> >> i have found a few exceptions written in plain, reasonably portable >> C, good for my purposes, >> but not characteristic of scientific applications in general. > > Agreed, and then there is the Netlib Java numerical analysis code -- That > one gave be indigestion... > > One of the biggest problems is that no one wants rewrite linpack, blas, > etc., not that it has been polished within an inch of the developers live= s. > > As for FORTRAN, I thought about looking into the old f2c, and see how tha= t > worked for getting some FORTRAN compiled in Plan 9 as a demonstration. = =C2=A0I'll > think about linuxemu in this context. > > =C2=A0EBo -- > > > --=20 Federico G. Benavento From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <8f46b210f655183b56d52e5737ace865@swcp.com> Date: Thu, 3 Feb 2011 13:07:05 -0800 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: abcd79f6-ead6-11e9-9d60-3106f5b1d025 On Thu, Feb 3, 2011 at 12:49 PM, Federico G. Benavento wrote: > I don't know if f2c meets your needs, but it has always worked. As compared to modern fortran compilers, it is basically a toy. ron From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <2c4856dc13ebea1ee1199551bf83b363@quintile.net> From: "Steve Simon" Date: Thu, 3 Feb 2011 21:32:24 +0000 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: abddbd48-ead6-11e9-9d60-3106f5b1d025 > > I don't know if f2c meets your needs, but it has always worked. > > > As compared to modern fortran compilers, it is basically a toy. > But he did say some of his source is in ratfor, I am pretty sure f2c would be happy with ratfor's output. years ago I supported the pafec FE package - tens of thousands of lines of Fortran. All the additions I made I did in ratfor, quite a reasonable language (compared to F77) I thought. -Steve From mboxrd@z Thu Jan 1 00:00:00 1970 From: John Stalker To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: <61b63bb81109d1b731fd899e371d271a@swcp.com> References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> <86ei7pkmhj.fsf@cmarib.ramside> <61b63bb81109d1b731fd899e371d271a@swcp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4236.1296774512.1@kryten-en0.lany63.cz> Date: Thu, 3 Feb 2011 23:08:38 +0000 Message-ID: <201102032308.aa76381@salmon.maths.tcd.ie> Subject: Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9 Topicbox-Message-UUID: abeef52c-ead6-11e9-9d60-3106f5b1d025 I don't write in fortran, but I certainly link to libraries written in it. It is a truly awful language in any of its incarnations, but sometimes the library you need is in fortran. Fortunately it's not to hard to link to from C once you understand its calling conventions and array ordering. > On Thu, 03 Feb 2011 18:21:28 +0000, smiley@zenzebra.mv.com wrote: > >> Ah. Thanks for the info. I asked because some of the physicists and > >> atmospheric scientists I work with are likely to insist on having > >> FORTRAN. I still have not figured how I will deal with that if at > >> all. > > > > I thought those folks used languages like Matlab & Mathematica for > > analysis, modeling, etc. At least those were what we used in the > > physics department @ RPI. > > Some of the scientists use those tools, but I am looking first at the > primary models like WRF , CMAQ and Air Quality>, etc., > > These are all written in FORTRAN 90/95/RatFOR, but some of the > underlying tools are written in C/C++, but only a few. If you can show > me a Matlab Global Circulation Model (even for a single cell, but which > accounts for the vertical profile and pressure) I'll arrange to buy you > a beer or your favorite beverage. > > I know of some of the energy budget models http://www.shodor.org/master/environmental/general/energy/application.html> > and similar things, but I would prefer to port something to HPD9 that > is a little more substantial. I want to couple various other models > like plant growth and survivorship, economics, etc. > > EBo -- > -- John Stalker School of Mathematics Trinity College Dublin tel +353 1 896 1983 fax +353 1 896 2282 From mboxrd@z Thu Jan 1 00:00:00 1970 To: <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 3 Feb 2011 17:12:23 -0600 From: EBo In-Reply-To: <201102032308.aa76381@salmon.maths.tcd.ie> References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> <86ei7pkmhj.fsf@cmarib.ramside> <61b63bb81109d1b731fd899e371d271a@swcp.com> <201102032308.aa76381@salmon.maths.tcd.ie> Message-ID: <81c08c9750134091fcba6a732a32872b@swcp.com> User-Agent: RoundCube Webmail/0.4-trunk Subject: Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9 Topicbox-Message-UUID: abf4c4ac-ead6-11e9-9d60-3106f5b1d025 On Thu, 03 Feb 2011 23:08:38 +0000, John Stalker wrote: > I don't write in fortran, but I certainly link to libraries written > in it. It is a truly awful language in any of its incarnations, but > sometimes the library you need is in fortran. Fortunately it's > not to hard to link to from C once you understand its calling > conventions and array ordering. Agreed, but is there a FORTRAN compiler/cross-compiler for Plan 9? Isn't the compiler for plan9port a wrapper for gcc? If so, that should work for my purposes, but in general? EBo -- From mboxrd@z Thu Jan 1 00:00:00 1970 To: <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Thu, 3 Feb 2011 17:19:47 -0600 From: EBo In-Reply-To: <2c4856dc13ebea1ee1199551bf83b363@quintile.net> References: <2c4856dc13ebea1ee1199551bf83b363@quintile.net> Message-ID: <92289389fa8e0c5bc4591ce66631939e@swcp.com> User-Agent: RoundCube Webmail/0.4-trunk Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: ac01da98-ead6-11e9-9d60-3106f5b1d025 On Thu, 3 Feb 2011 21:32:24 +0000, Steve Simon wrote: >> > I don't know if f2c meets your needs, but it has always worked. >> >> >> As compared to modern fortran compilers, it is basically a toy. >> > > But he did say some of his source is in ratfor, > I am pretty sure f2c would be happy with ratfor's output. > > years ago I supported the pafec FE package - tens of thousands of > lines > of Fortran. All the additions I made I did in ratfor, quite a > reasonable > language (compared to F77) I thought. Yes, I mentioned f2c WAY back in the thread. That was something I was going to try first. As for ratfor, I am not sure how much of that code I have to contend with, but I am aware of it's existence (and have written a few thousand lines in the distance past). EBo -- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <20110202191924.5AD2E5B3B@mail.bitblocks.com> References: <20110202191924.5AD2E5B3B@mail.bitblocks.com> Date: Thu, 3 Feb 2011 22:54:09 -0700 Message-ID: From: andrey mirtchovski To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: ac68a8a4-ead6-11e9-9d60-3106f5b1d025 > $ size /usr/local/bin/clang > =C2=A0 text =C2=A0 =C2=A0data =C2=A0 =C2=A0 bss =C2=A0 =C2=A0 dec =C2=A0 = =C2=A0 hex filename > 22842862 =C2=A0 =C2=A0 =C2=A0 =C2=A01023204 =C2=A0 69200 23935266 =C2=A0 = =C2=A0 =C2=A0 =C2=A016d3922 /usr/local/bin/clang "It is interesting to note the 5 minutes reduction in system time. I assume that this is in part because of the builtin assembler." -- http://blog.mozilla.com/respindola/2011/02/04/clang-results/ From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Thu, 03 Feb 2011 15:33:57 EST." <7c9185b80ba40fd32ba3aa75bdcc8fcf@ladd.quanstro.net> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> <20110203174129.C984D5B91@mail.bitblocks.com> <20110203183304.648355B91@mail.bitblocks.com> <05360a88f7a0cd797278d6bd6a3ae73f@ladd.quanstro.net> <20110203194058.8F4B55B91@mail.bitblocks.com> <7c9185b80ba40fd32ba3aa75bdcc8fcf@ladd.quanstro.net> From: Bakul Shah Date: Thu, 3 Feb 2011 23:16:05 -0800 Message-Id: <20110204071605.E2F955B92@mail.bitblocks.com> Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: ac6f5fc8-ead6-11e9-9d60-3106f5b1d025 On Thu, 03 Feb 2011 15:33:57 EST erik quanstrom wrote: > > I must also say llvm has a lot of functionality. But even so > > there is a lot of bloat. Let me just say the bloat is due to > > many factors but it has far *less* to do with graphs. > > Download llvm and take a peek. I think the chosen language > > and the habits it promotes and the "impedance match" with the > > problem domain does play a significant role. > > do you know of a compiler that uses a > graph-based approach that isn't huge? Stalin (source code ~3300 lines). There are others. > > Or something equivalent. Example: How do you know moving an > > expression out of a for loop is valid? The optimizer needs to > > understand the control flow. > > is this still a useful thing to be doing? Yes. From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Fri, 4 Feb 2011 09:38:12 -0500 To: 9fans@9fans.net Message-ID: In-Reply-To: <20110204071605.E2F955B92@mail.bitblocks.com> References: <2c752317a96b7b8b980ad37e92ff6f01@terzarima.net> <20110203021608.006575B67@mail.bitblocks.com> <2c48b8397b29ededd862efa6de0baf70@brasstown.quanstro.net> <20110203174129.C984D5B91@mail.bitblocks.com> <20110203183304.648355B91@mail.bitblocks.com> <05360a88f7a0cd797278d6bd6a3ae73f@ladd.quanstro.net> <20110203194058.8F4B55B91@mail.bitblocks.com> <7c9185b80ba40fd32ba3aa75bdcc8fcf@ladd.quanstro.net> <20110204071605.E2F955B92@mail.bitblocks.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely Topicbox-Message-UUID: ac7687a8-ead6-11e9-9d60-3106f5b1d025 > > > Or something equivalent. Example: How do you know moving an > > > expression out of a for loop is valid? The optimizer needs to > > > understand the control flow. > > > > is this still a useful thing to be doing? > > Yes. what's your argument? my argument is that the cpu is so fast relative to the network and disk, that wasting a few cycles is a good tradeoff for compiler and debugging simplicity, and compile speed. further, i'm not sure the compiler is in a position to know when strength reduction will make sense. intel, for example, does a lot of optimization that is "not architectural". that's code that means they won't tell you what will be a net win. i can think of a number of things that might defeat moving code out of a loop, such as the computation using otherwise idle functional units, keeping the value in the trace cache, keeping the value out of l2, the loop detector, etc. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Sat, 5 Feb 2011 11:54:08 -0800 From: Lyndon Nerenberg To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-Reply-To: <81c08c9750134091fcba6a732a32872b@swcp.com> Message-ID: References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> <86ei7pkmhj.fsf@cmarib.ramside> <61b63bb81109d1b731fd899e371d271a@swcp.com> <201102032308.aa76381@salmon.maths.tcd.ie> <81c08c9750134091fcba6a732a32872b@swcp.com> User-Agent: Alpine 1.10 (OSX 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9 Topicbox-Message-UUID: ace12c16-ead6-11e9-9d60-3106f5b1d025 > Agreed, but is there a FORTRAN compiler/cross-compiler for Plan 9? f2c (from netlib) is trivial to get running. This gives you Fortran 77. It has been sufficient for my needs (spice, zork, some grib stuff). --lyndon From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Huntsman To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Date: Sat, 5 Feb 2011 20:32:41 +0000 Message-ID: <5782C16A7C920E469B74E11B5608B8E7089FACEF@Kriegler.ntdom.cupdx> References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> <86ei7pkmhj.fsf@cmarib.ramside> <61b63bb81109d1b731fd899e371d271a@swcp.com> <201102032308.aa76381@salmon.maths.tcd.ie> <81c08c9750134091fcba6a732a32872b@swcp.com>, In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9 Topicbox-Message-UUID: acef8f86-ead6-11e9-9d60-3106f5b1d025 > Agreed, but is there a FORTRAN compiler/cross-compiler for Plan 9? I remember someone on here mentioning having a "translator" that could prod= uce plan 9 executables from output from XLC or XLF as part of the Blue Gene= stuff... don't remember the exact details, but that sounds like a very wor= thy piece of software... From mboxrd@z Thu Jan 1 00:00:00 1970 To: <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 5 Feb 2011 15:17:51 -0600 From: EBo In-Reply-To: <5782C16A7C920E469B74E11B5608B8E7089FACEF@Kriegler.ntdom.cupdx> References: <38899c887189359a27e790996ae92c00@terzarima.net> "<78c41896424e345485cd1d783502fd9e@swcp.com>" <86ei7pkmhj.fsf@cmarib.ramside> <61b63bb81109d1b731fd899e371d271a@swcp.com> <201102032308.aa76381@salmon.maths.tcd.ie> <81c08c9750134091fcba6a732a32872b@swcp.com>, <5782C16A7C920E469B74E11B5608B8E7089FACEF@Kriegler.ntdom.cupdx> Message-ID: <72f5231a1cf24c27c0e795f0e3f67825@swcp.com> User-Agent: RoundCube Webmail/0.4-trunk Subject: Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9 Topicbox-Message-UUID: acf6195a-ead6-11e9-9d60-3106f5b1d025 On Sat, 5 Feb 2011 20:32:41 +0000, Benjamin Huntsman wrote: > I remember someone on here mentioning having a "translator" that > could produce plan 9 executables from output from XLC or XLF as part > of the Blue Gene stuff... don't remember the exact details, but that > sounds like a very worthy piece of software... I would really like to see if this can be tracked down and if it is available. EBo -- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <5782C16A7C920E469B74E11B5608B8E7089FACEF@Kriegler.ntdom.cupdx> References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> <86ei7pkmhj.fsf@cmarib.ramside> <61b63bb81109d1b731fd899e371d271a@swcp.com> <201102032308.aa76381@salmon.maths.tcd.ie> <81c08c9750134091fcba6a732a32872b@swcp.com> <5782C16A7C920E469B74E11B5608B8E7089FACEF@Kriegler.ntdom.cupdx> Date: Sat, 5 Feb 2011 13:49:17 -0800 Message-ID: From: ron minnich To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9 Topicbox-Message-UUID: acfcbd1e-ead6-11e9-9d60-3106f5b1d025 On Sat, Feb 5, 2011 at 12:32 PM, Benjamin Huntsman wrote: >> Agreed, but is there a FORTRAN compiler/cross-compiler for Plan 9? > > I remember someone on here mentioning having a "translator" that could produce plan 9 executables from output from XLC or XLF as part of the Blue Gene stuff... don't remember the exact details, but that sounds like a very worthy piece of software... unless your memory confused that with the fact that I can run Blue Gene binaries produced by XLC/XLF, I don't recall what you mean ... ron From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Huntsman To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Date: Sat, 5 Feb 2011 23:12:33 +0000 Message-ID: <5782C16A7C920E469B74E11B5608B8E7089FAD12@Kriegler.ntdom.cupdx> References: <38899c887189359a27e790996ae92c00@terzarima.net> <78c41896424e345485cd1d783502fd9e@swcp.com> <86ei7pkmhj.fsf@cmarib.ramside> <61b63bb81109d1b731fd899e371d271a@swcp.com> <201102032308.aa76381@salmon.maths.tcd.ie> <81c08c9750134091fcba6a732a32872b@swcp.com> <5782C16A7C920E469B74E11B5608B8E7089FACEF@Kriegler.ntdom.cupdx>, In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9 Topicbox-Message-UUID: ad088cf2-ead6-11e9-9d60-3106f5b1d025 >unless your memory confused that with the fact that I can run Blue >Gene binaries produced by XLC/XLF, I don't recall what you mean ... > >ron Haha, yes, that's it. My memory indeed got confused. Sorry for the noise! From mboxrd@z Thu Jan 1 00:00:00 1970 To: <9fans@9fans.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Sat, 5 Feb 2011 18:25:55 -0600 From: EBo In-Reply-To: <5782C16A7C920E469B74E11B5608B8E7089FAD12@Kriegler.ntdom.cupdx> References: <38899c887189359a27e790996ae92c00@terzarima.net> "<78c41896424e345485cd1d783502fd9e@swcp.com>" <86ei7pkmhj.fsf@cmarib.ramside> <61b63bb81109d1b731fd899e371d271a@swcp.com> <201102032308.aa76381@salmon.maths.tcd.ie> <81c08c9750134091fcba6a732a32872b@swcp.com> <5782C16A7C920E469B74E11B5608B8E7089FACEF@Kriegler.ntdom.cupdx>, <5782C16A7C920E469B74E11B5608B8E7089FAD12@Kriegler.ntdom.cupdx> Message-ID: <8d06c25dc4fc0ad6cf90e49ae4e9e27d@swcp.com> User-Agent: RoundCube Webmail/0.4-trunk Subject: Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9 Topicbox-Message-UUID: ad179274-ead6-11e9-9d60-3106f5b1d025 On Sat, 5 Feb 2011 23:12:33 +0000, Benjamin Huntsman wrote: >>unless your memory confused that with the fact that I can run Blue >>Gene binaries produced by XLC/XLF, I don't recall what you mean ... > > Haha, yes, that's it. My memory indeed got confused. Sorry for the > noise! :-(