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:14  PM, Luke Kenneth Casson Leighton 
wrote:
>  i think you may find that a less stringent goal - of doing
>  "outsourcing" - may result in an intermediate useable compromise
>  that would keep most people happy or at least a whole damn lot
>  more happy than they are at the moment.

My take, the numbers of people that face 50+ wide things is very small. 
 Doing compiler work is expensive (more expensive than just learning 
and coding assembler).  The architecture is uncompilable, if there are 
so few people doing it, that the compiler doesn't support it.  When 
there are enough people using it, then it is important to expend the 
energy (bucks) to make the compiler support it.

Look at ia64 for example, seemed like a good idea to someone, and yet, 
even with large amounts of $ thrown at it, it isn't capturing the 
hearts and minds of people, in part seemingly due to inadequate tools.

The compiler is _part_ of the architecture costs, and if people are 
going to pay that cost, then they will wind up with something that they 
will force users to code in assembly for, and as you say, with training 
that can cost 6 months of time.  In the end, the companies promoting 
the architecture, will have to make those valuations and fund the work, 
or not; and live and die by those decisions.

>  and the key reason why all these things are a pain in the
>  arse is because you cannot "abstract" it out to c++

I've not familiar with that proof.  I've seen very many odd things done 
with C++ and it seems to me that it would be possible to abstract it 
out.

>  - you  _have_ to go to assembler, you _have_ to make use of macros
>  (which don't mix with c++ templates).

?  I don't know that.  I'd prefer you went to comp.lang.c++ and 
challenged them with I bet this can't be done, and had someone sketch 
out how to do it, or do it.  Certainly we designed it (C++) in part 
with the idea that one could have exotic hardware behind some of the 
classes (valarray) and get the speed.

See the altivec intrinsics or the mmx/sse/sse2/sse3 intrinsics for a 
sketch of an existance proof on why one never would need assembler to 
do anything.

> well, i do, but it's many _many_ steps removed from becoming a reality 
> - funding,

No, funding is a _primary_ concern.  Either, people that want the 
architecture to succeed pay for it, convince grad students that it 
would be a good research area, or, well, you write in assembler.  This 
list is a poor place, when it comes to funding issues.

>   ... you can tell that i really loved the processor design and the
>  opportunity to work with something that radical, though.

There have been neat architectures that I liked, but, that failed the 
market reality testcase, in the end, it isn't about being neat, it is 
about price/performance and giving a customer what they want.

>  it's because i am looking to recommend to a company that is
>  doing a parallel processor design that they also provide a
>  vector processor unit.

:-)  If they only support constructs that can be easily be used by gcc, 
and if they customers need it, and if there is a large market for the 
architecture where they can beat ia32 and AMD-64 now, and in the next 3 
years, then, they might have a chance to not fail.  Otherwise, well, 
you can do anything you want, because they will fail, just be sure to 
get your money up front, don't work for free or stock...  :-)

>  if gcc don't make the grade as a viable vector processing aware
>  compiler or as part of a vector processing aware toolchain,
>  the recommendation ain't gonna happen - i've seen what happens
>  when you don't have a good enough development toolchain.
>
>  companies fail.

Yup.


So, while it may seem like you can escape out to perl and code up a 
compiler assist in perl, our best sense tells us to dissuade you from 
that idea.  Better to recognize the code (autovec) or use tagging 
techniques (OpenMP/altivec/sse) and then just do up that support 
directly in the compiler, plus, now-a-days, I would recommend doing up 
a template library that makes the architecture rock; to make that work, 
it also needs to be ported to all the market relevant architectures as 
well and have a massive user following.  That part is beyond the scope 
of this list.