<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 26, 2018 at 4:28 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><font color="#0000ff"><font face="arial, helvetica, sans-serif">I don't think there was any technical reason that
        the front end, IL optimizer, code generators and object
        generators couldn't have been separate sharable libraries - and
        separately patchable/upgradable.  </font></font></div></blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#ff0000">​I was under the impression that the shared libraries were just that and DEC was pretty tight about if the fix was in the backend, all front end languages had to be tested (more in a minute).​</font></div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><font color="#0000ff"><font face="arial, helvetica, sans-serif">But I suspect there was
        marketing (and qualification) pull toward hiding the boundaries
        when packaging.</font></font></div></blockquote><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#ff0000">​Maybe in marketing (undeserved) but qual was in important.​</font></div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><font color="#0000ff"><font face="arial, helvetica, sans-serif">After all, some 3rd party might have written a
        backend for a non-DEC architecture.<br></font></font></div></blockquote><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#ff0000">​Unlikely -  the sad truth is that when both the K&A folks and Intel compiler groups had access to the all the code and the doc (and the people that designed it), guess what code base was used..  not GEM.​</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#ff0000"><br></font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#ff0000">Grove used to say the DEC (Gem) compiler DNA was being ground up and reinserted into the Intel compiler.   To this day the Intel IL is not as rich as the Gem IL and it drives a lot of the old DEC team crazy.   From what I gather, the closest IL has been what LLVM did, but I gather than is still pretty weak for some language structures such as FORTRAN (and I believe PL/1).</font></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><font color="#ff0000"><br></font></div><div class="gmail_default"><font color="#ff0000"><font face="arial, helvetica, sans-serif">Speaking for myself and my own personal experiences in using the both the DEC and Intel tool chains over the years, the common back-end/runtime is </font></font><font color="#ff0000" face="arial, helvetica, sans-serif">acute and you see how well Gem did vs an issue Intel has had.   I've spent years trying to get the testing and installer folks to 'get it'  when it comes to dependancies (I was once given an Intel div level award for 'fixing' this issue - although 5 years later I discovered much of the work we had done had been lost and I had a deal into a new group numbskulls -- sigh - I do think it is current correct - if you believe/know otherwise sent me email offline).</font></div><div class="gmail_default"><font color="#ff0000" face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font color="#ff0000" face="arial, helvetica, sans-serif">Intel Fortran (like DEC Fortran) is dependent on the actually source language specific runtime (because it's written in C or BLISS) and both runtimes are dependent on a bunch of common runtime code, not just language specific stuff.   If you make a change to the last or middle ones: you have to ensure that you test what is dependent upon; and and when you install don't create (and release) private versions.  i.e. install common runtimes, then Fortran specific, then the Fortran compiler etc...   I'm always amazed that such a simple idea is lost on some of the installation folks (as much as a I used to b*tch at the DEC setld installer team, they did tend to get this right).</font></div><div class="gmail_default"><font color="#ff0000" face="arial, helvetica, sans-serif"><br></font></div><div class="gmail_default"><font color="#ff0000" face="arial, helvetica, sans-serif"><br></font></div><div> </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=96e9b59b-d26c-470f-a65f-b3da6ea768d0"><font color="#ffffff" size="1">ᐧ</font></div>