Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Jacob Todd]

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

And russ cox, and everyone else in the CONTRIBUTORS file.
On Feb 2, 2011 12:39 AM, "Scott Sullivan" <scott@ss.org> wrote:

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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[ron minnich]

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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Bakul Shah]

On Tue, 01 Feb 2011 23:06:33 PST ron minnich <rminnich@gmail.com>  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?

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Lucio De Re]

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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Nick LaForge]

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 <jaketodd422@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:
>

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[David Leimbach]

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

On Tue, Feb 1, 2011 at 11:35 PM, Nick LaForge <nicklaforge@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.  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 <jaketodd422@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:
> >
>
>

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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Bakul Shah]

On Wed, 02 Feb 2011 09:45:56 PST David Leimbach <leimy2k@gmail.com>  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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Charles Forsyth]

>$ 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'.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[erik quanstrom]

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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Charles Forsyth]

> >$ 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?

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[ron minnich]

On Wed, Feb 2, 2011 at 4:52 PM, Charles Forsyth <forsyth@terzarima.net> 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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Bakul Shah]

On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth <forsyth@terzarima.net>  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.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[David Leimbach]

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

On Wed, Feb 2, 2011 at 6:16 PM, Bakul Shah
<bakul+plan9@bitblocks.com<bakul%2Bplan9@bitblocks.com>
> wrote:

> On Thu, 03 Feb 2011 00:52:35 GMT Charles Forsyth <forsyth@terzarima.net>
>  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

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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[erik quanstrom]

> 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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[David Leimbach]

On Wednesday, February 2, 2011, erik quanstrom <quanstro@quanstro.net> 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.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Eugene Gorodinsky]

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

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 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.
>
>

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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Bakul Shah]

On Thu, 03 Feb 2011 07:08:57 PST David Leimbach <leimy2k@gmail.com>  wrote:
> On Wednesday, February 2, 2011, erik quanstrom <quanstro@quanstro.net> 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.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[erik quanstrom]

> 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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Bakul Shah]

On Thu, 03 Feb 2011 13:11:07 EST erik quanstrom <quanstro@quanstro.net>  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.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[erik quanstrom]

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 <quanstro@quanstro.net>  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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Bakul Shah]

On Thu, 03 Feb 2011 13:54:05 EST erik quanstrom <quanstro@quanstro.net>  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 <quanstro@quanstro.net>  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.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[erik quanstrom]

> 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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Bakul Shah]

On Thu, 03 Feb 2011 15:33:57 EST erik quanstrom <quanstro@quanstro.net>  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.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[erik quanstrom]

> > > 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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Joseph Stewart]

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

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

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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Charles Forsyth]

>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.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[EBo]

 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 --

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Charles Forsyth]

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.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[EBo]

 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 --

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Lucio De Re]

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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[C H Forsyth]

> 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.

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[EBo]

 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 --

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Federico G. Benavento]

I don't know if f2c meets your needs, but it has always worked.

On Thu, Feb 3, 2011 at 9:07 AM, EBo <ebo@sandien.com> 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 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 --
>
>
>



-- 
Federico G. Benavento

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[ron minnich]

On Thu, Feb 3, 2011 at 12:49 PM, Federico G. Benavento
<benavento@gmail.com> 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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[Steve Simon]

> > 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

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[EBo]

 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 --

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[smiley]

EBo <ebo@sandien.com> 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|
+---------------------------------------------------------------+

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[John Floren]

On Thu, Feb 3, 2011 at 10:21 AM,  <smiley@zenzebra.mv.com> wrote:
> EBo <ebo@sandien.com> 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.
>

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

[9fans] FORTRAN and tools [was: Modern development language for Plan 9

[EBo]

 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 <Weather Forcast>, CMAQ <Congestion Mitigation
 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 <ex:
 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 --

Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9

[John Stalker]

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 <Weather Forcast>, CMAQ <Congestion Mitigation
>  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 <ex:
>  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

Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9

[EBo]

 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 --

Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9

[Lyndon Nerenberg]

> 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

Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9

[Benjamin Huntsman]

> 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...

Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9

[EBo]

 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 --

Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9

[ron minnich]

On Sat, Feb 5, 2011 at 12:32 PM, Benjamin Huntsman
<BHuntsman@mail2.cu-portland.edu> 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

Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9

[Benjamin Huntsman]

>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!

Re: [9fans] FORTRAN and tools [was: Modern development language for Plan 9

[EBo]

 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!

 :-(

Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[andrey mirtchovski]

> $ size /usr/local/bin/clang
>   text    data     bss     dec     hex filename
> 22842862        1023204   69200 23935266        16d3922 /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/