<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">a tad OT for simh ...l</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 28, 2018 at 3:42 PM, Timothe Litt <span dir="ltr"><<a href="mailto:litt@ieee.org" target="_blank">litt@ieee.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><font color="#ff0000"><font color="#000000"><br>
        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?" </font></font></div></blockquote><div><div class="gmail_default"><font color="#0000ff"><font face="arial, helvetica, sans-serif">​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. </font></font></div><div class="gmail_default"><font color="#0000ff"><font face="arial, helvetica, sans-serif"><br></font></font></div><div class="gmail_default"><font color="#0000ff"><font face="arial, helvetica, sans-serif">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.  </font></font></div><div class="gmail_default"><font color="#0000ff"><font face="arial, helvetica, sans-serif"><br></font></font></div><div class="gmail_default"><font color="#0000ff"><font face="arial, helvetica, sans-serif">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.  </font></font></div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><font color="#ff0000"><font color="#000000"> <br>
        <br>
        Of course, both share the same defect - a shortsighted world
        view.  Which is easy to see a few decades later.<br></font></font></div></blockquote><div><div class="gmail_default"><font color="#0000ff"><font face="arial, helvetica, sans-serif">​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:  </font></font><a href="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">Clem-Cole's Quora Answer - Why is Fortran Still in Use</a><font color="#0000ff">].</font></div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><font color="#ff0000"><font color="#000000"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">​... ​</div>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. </font></font></div></blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">​Exactly!!!​</font></div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><font color="#ff0000"><font color="#000000"> 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 :-)<br></font></font></div></blockquote><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">​+1 :-)</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><font color="#ff0000"><font color="#000000">
        <br>
        Old New England axiom: Never time to do it right; always time to
        do it over.<br>
        <br>
        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.<br>
        <br>
        Neither is put to use in the technology world...at least not
        often.<br></font></font></div></blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">​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,​</font></div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <br>
    INTC studied software development with M$, adopting its practices. 
    (Not necessarily its best ones.)<br>
    <br>
    Q.E.D.<br></div></blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">​+1 ​</font></div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <br><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;display:inline">​... ​</div>those who don't learn from
    history are doomed to repeat it?<br>
    <br>
    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.</div></blockquote><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">​<font color="#0000ff">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.</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#0000ff">Clem</font></div></div></div></div><div hspace="streak-pt-mark" style="max-height:1px"><img alt="" style="width:0px;max-height:0px;overflow:hidden" src="https://mailfoogae.appspot.com/t?sender=aY2xlbWNAY2NjLmNvbQ%3D%3D&type=zerocontent&guid=9ccd9c30-b084-4788-9f30-9e80ab75043c"><font color="#ffffff" size="1">ᐧ</font></div>