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