a tad OT for simh ...l On Sun, Jan 28, 2018 at 3:42 PM, Timothe Litt <l...@ieee.org> wrote:
> > In the current STC, well, I saw a lot of NIH in Intel. I suspect that > what you report amounts to "Why tear up a "perfectly good compiler" to > incorporate technology from a "failed company", when the result isn't > directly marketable?" > I understand. Although if I believe what Stan Whitlock, Dave Eklund, and Paul Winalski [3 of DEC more illustrious compiler folks for those that do not recognize the names] have always claimed is that when they started hacking on the Intel compiler, their were more open bug reports than ever been reported bugs on Gem. That does not say it was a perfectly good compiler. Although the fact that Gem had been written in BLISS vs. C I think colored the opinion/choice/was the reason given; but I've heard similar things from the ex-K&A folks who had much of their technology in C. To be honest, I think what drove Rich and the team nuts the most was not the implementations as much as the lack of the support for things in IL that DEC handled years ago. As you pointed out, GEM's IL was designed for N input languages and Y backends ... AND ... supported CISC and RISC architectures and even had support for parallel ops. Until LLVM came on the scene, I'm not aware of any other compiler technology that was as flexible - although like you, as an OS guy I follow compiler stuff as a very interested user/observer -- much less lunch companion to the folks building it all. > > > Of course, both share the same defect - a shortsighted world view. Which > is easy to see a few decades later. > Well, I think there is pride of authorship/NIH; and then practical realities. LLVM is the current 'savior' for the community, but to be honest, its still unproven. There is not yet a modern ''commercial style'' FORTRAN or PL/1 front-ends and parallel ops are still a work-in-progress. That may change. But as I have said here and in other places, Fortran (and parallel Fortran in particular) pays my salary and I don't think that is going to change for a long time because too >>production<< code is written in it [See: Clem-Cole's Quora Answer - Why is Fortran Still in Use <https://www.quora.com/Why-is-the-Fortran-language-still-in-use-and-most-importantly-relevant-in-HPC-Is-it-just-because-this-language-has-tremendous-numerical-calculation-capability-which-is-an-important-part-of-HPC/answer/Clem-Cole> ]. > ... > GEM was built & evolved by engineers from the ground up to support > multiple languages at equivalent optimization levels. Most other ILs start > as an internal tool for one language; when extended, the rule is to make > minimal changes to support each additional language. > Exactly!!! > This keeps short term costs down (regressions against and changes to the > first language - and tools), but you lose expressiveness (and > optimizations). And it ends up being warty and hackish. But the > incremental cost of the next wart/hack is always less than the cost of > rototilling. There's probably a formal proof to derive NIH from this > observation :-) > +1 :-) > > Old New England axiom: Never time to do it right; always time to do it > over. > > Knuth's version: When writing software, do it once to understand the > problem. Then plan on throwing out what you built, and write it correctly > from scratch. > > Neither is put to use in the technology world...at least not often. > Amen -- IMO (and a many others) the best engineering manager the SW world ever produced (Roger 'Fossil' Gourd) use to try to teach this lesson. I miss his wisdom, > > INTC studied software development with M$, adopting its practices. (Not > necessarily its best ones.) > > Q.E.D. > +1 > > ... > those who don't learn from history are doomed to repeat it? > > SimH does a great job of preserving the ability to use the artifacts. > However, preserving the knowledge that created them is a different problem, > as yet unsolved. > I hope these and pages like TUHS are a small attempt to do some of it, although I fear not enough people that are writing new code read. Bless you of trying to remember and get it down as a start. Clem ᐧ
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
