[Simh] DEC GEM vs. Intel compilers

[Clem Cole]

a tad OT for simh ...l

On Sun, Jan 28, 2018 at 3:42 PM, Timothe Litt <litt at 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
ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180129/0901a79a/attachment.html>