Re: [lkcl@lkcl.net: has gcc been reworked so that code/templates can be "outsourced" e.g. to perl yet?]

[Mike Stump <mrs at apple dot com>]

On Sunday, May 15, 2005, at 01:01  PM, Luke Kenneth Casson Leighton 
wrote:
> unfortunately, integration of aspex's proprietary tool-chain - written
> in modula-2 - is extremely unlikely to ever be integrated into gcc.

Right.  But the ideas could be.  The ideas in some respects are more 
important than the code.

> secondly, the code it generates is c-code - not any kind of assembler.

Not a problem, the internal tree structure in the compiler, where one 
would target such code generation is not any kinda of assembler either. 
 Looks more like, uhm, C.  :-)

> that c-code places instructions onto a memory-mapped FIFO queue.

As can the tree code.

> the PCI card containing the ASP processors can go
> into _any_ standard hardware with _any_ standard processor.

While gcc doesn't usually do this, I don't see a compelling reason why 
it cannot, though, it would be a bit hard to do the first one.

> additionally, full and transparent integration (i.e. automatic
> recognition of arrays of ints and turning them into 
> hardware-accelerated
> ASP code) is a YET MORE complex task.

And yet, gcc already does this.  This is the power of using gcc, you 
don't have to code this to get it, you get it for free.

> regenerating template-instantiated code-fragments, "outsourcing" them
> to aspex's toolchain and re-running context-sensitive gcc parsing on 
> them
> is the most "sane" from-here-to-there way that i can think of doing
> things.

Ok.  Certainly you can do this, gcc is free, and is meant to allow 
people the freedom to do this, I just doubt that we'd be interested at 
all in the work, either helping you code, giving help, advice and 
directions or even incorporating it.  Put another way, that path is 
lonely.

> it also represents an alternate "way out" that doesn't force
> you to go the whole hog of [MasPar?

We seem already committed to doing that.  So, it doesn't save anything.

>  i presume by OpenMP you mean maspar] MP's "plural" syntax.

See google("OpenMP") for what I mean by OpenMP.

> you are NEVER - not if you are in your right mind - going to
> get THAT integrated into gcc.  EVER.

Ok, yes, I agree.  For example, one could have a group of 4 Xilinx 
chips on a daughter card, and it would be nice to expose those 
resources to the compiler, and have it do something intelligent with 
it, this isn't going to happen.  In the end, it would require someone 
setting up a range of allowable things one can have, and then to 
generate `code' for that.

But, one can come up with sufficiently small subsets of that, that are 
useful, and make that work vend that to customers, collect money for 
it, and then plow that back into the process and do yet more with it.  
Without a customer, well, let's just say, grad students would be the 
next best thing, who else would do a months worth of work for $100.

> ... all that having been said, i would _love_ to see the MP
> "plural" syntax integrated back into gcc.

See below...  grab gcc, apply the patches...

> i _did_ spend a significant amount of effort trying to track
> down the original MP-modified tarball - several months, in fact.

You can grab a current version on the gcc mailing list.  See a port by 
rth in the past week or so.  OpenMP in the subject line, as I recall.