Lambda the Ultimate

Users of AMD chips should read this curious article.

Personally I prefer Digital Mars C++ (long story; don't ask).

From my soap box let me reiterate how back-end retargeting issues hinder technological progress and embedded work.

Ehud, the Register article mentions a chip designed to run Ada.

Recently I've been viewing some of Dan Grossman's Cyclone slides. Worth a look. What interests me is not Yet Another VM or Yet Another JIT or CLR but rather, some kind of intermediate target language like ML-RISC that enables "write once, retarget anywhere."

A very ambitious project for its time.

http://www.brouhaha.com/~eric/retrocomputing/intel/iapx432/

Capability-based addressing, multiple CPU and IO processors on the bus, object-based memory and persistence, etc.

Obviously way ahead of its time, with too much overhead especially in the bus design so not only were the processors slow, but the system could not scale as needed.

Dejan: As I recall, Intel bought KAI with the idea of marrying Intel's back end to KAI's front end. That move took KAI C++ off the market. One might conclude that Intel is not a software house. Tiny KAI produced such a superior front end that giant Intel scrapped its own.

Real progress will come through (1) portable intermediate target languages and (2) new chips built from scratch, not x86 baselines. Then (1) yields free chip support for various languages, and new chips (2) benefit from instant language availability, creating a symbiotic evolution. Right now Intel has a hard time growing its own chip line under a mere C++ regime.

However, nothing says Intel will like the idea of portable intermediate target languages. Intel has no problem keeping compiler vendors busy optimizing back-ends for Intel chips...leaving them no time to re-target. While favorable for Intel, that situation is far from optimal for overall language progress. If and when compiler developers start using portable intermediate languages, the world will be a very different place.

Having said all that, I do respect the technical merits of the Intel work represented here.

But remember, the compiler is not a core product for them. It's something they have to do to bootstrap development for their own chips.

Intel is serving its own purposes, like any corporation should.

My comment, however, was about the general code quality of software written by/for the hardware vendors. The only two companies that write good drivers are Intel and NVidia. The others just plain suck.

Intel never had their own front end for C++. Before KAI they used the EDG front end....But remember, the compiler is not a core product for them.

That Intel has not written any front end echoes my point more strongly, that it's not a software company. I was not the one who commented about Intel software. My statement was that chips are their core product. I stretch and suggest that Intel chip dominance impacts programming language progress.

My comment...was about the general code quality of software written by/for the hardware vendors.

With that comment I agree and it leads into my thesis. Hardware vendors are poor software houses and all embedded developers know it. That is one reason h/w vendors should not bear the burden of compiler development. Nonetheless that is the modern situation: chip vendors sell C/C++ compilers specific to their chips (TI DSP, PIC, Sharc, etc.). Developers have no language choice and half-baked C tools, as a rule. The chip vendors won't get back-end support from language groups because language groups barely have time to support the dominant Intel architecture. Yet the chip vendors must provide dev tools, or they can't sell chips. Hence the burden of compiler support.

Now consider an alternative scenario. Suppose all these chip vendors, instead of proliferating C++ compilers, would redirect efforts into chip-specific back-ends for a common intermediate target language. Now we have a true division of labor with all the benefits of specialization. By virtue of the IL, each of these back-ends supports any language, not just C++. Meanwhile language developers target the IL once and have instant support on all compliant back-ends (chips). Language authors get portability. Developers get language flexibility and quality tools for a change. Chip vendors get free language support and compete over hardware merits, not dev tools. Third-party hardware designers are not forced into selecting Intel chips over s/w dev tool issues (that does happen). So to address these remarks,

It's something they have to do to bootstrap development for their own chips.

The IL approach could serve equally well.

Intel is serving its own purposes, like any corporation should.

Not completely; as one of the articles says, Intel can't even grow its own chip line because of dev tools. The vertical integration strategy creates problems for Intel's technical progress (not to say money-making, since they can still sell old tech and enjoy market dominance).

Rather than saying to ourselves, "Wow, Intel alone among hardware vendors makes great software!" we should ask, "Wow, why the heck are hardware vendors selling C++ compilers, when even the best of them outsources the front-end work?" In an ideal world Intel would found a consortium of chip companies which would hire PL experts to design an open IL for everyone. However until PL folks decide they want portability, and stop expending all their back-end energies on Intel architectures alone, Intel has no motivation to change. That is a PL community issue and why I raise it on LtU.