<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<div class="moz-cite-prefix">On 27-Jan-18 13:59, Clem Cole wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAC20D2N2z04bq7n4We1s-E5GRfnssKsW1B4Kv_60SJTb1LHS0A@mail.gmail.com">
<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"
moz-do-not-send="true">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>
</div>
</div>
</div>
</blockquote>
I could be wrong - I followed GEM development off and on as a matter
of curiosity, but didn't get into the internals - however, I was
under the impression that GEM was built into the compilers from
object libraries, not linked as sharable images. In any case, GEM
was not exposed or documented externally. And I don't recall any
language-independent patch being issued for GEM - common issues
resulted in a patch for each language - however things were
packaged.<br>
<br>
What was regression tested internally was quite different from what
was released. BLISS was regression tested daily, but rarely
released (even internally). IIRC, there were a lot of GEM changes
to support C optimization and FORTRAN parallelization. (And
language changes.) And those languages were released fairly
frequently to satisfy customers & benchmarks. But I tracked
progress through the GEM and language notesfiles, so I may have a
skewed view. <br>
<br>
<blockquote type="cite"
cite="mid:CAC20D2N2z04bq7n4We1s-E5GRfnssKsW1B4Kv_60SJTb1LHS0A@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<font color="#ff0000"><font color="#000000">That's reality - in a
different space-time continuum. <br>
<br>
In the original (DEC-centric) STC, those decisions were made
from the point of view of DEC being the center of the universe,
and not wanting DEC's IP to leak onto other architectures.
Either BLISS itself, or products coded in it. The same view
that didn't license XMI; greatly restricted BI licenses; and was
too little too late with expanding the Alpha ecosystem.
(Contrast with PDP-11, where every Unibus system came with a
license grant to build a peripheral...)<br>
<br>
Similarly, the DECision on BLISS pricing made sense if you
looked at what DEC invested (I think Brender's paper said a team
of 16 people (pre-GEM) and a couple of $M) and what having it
was worth to DEC engineering. It didn't recognize how customers
would value BLISS, or what adoption by a wider crowd would be
worth to DEC in the long run.<br>
<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?" <br>
<br>
Of course, both share the same defect - a shortsighted world
view. Which is easy to see a few decades later.<br>
<br>
</font></font>
<blockquote type="cite"
cite="mid:CAC20D2N2z04bq7n4We1s-E5GRfnssKsW1B4Kv_60SJTb1LHS0A@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</div>
</blockquote>
<font color="#ff0000"><font color="#000000">I wouldn't know; it's
been a long time since I dabbled in compilers. Mostly pre-GEM
timeframe. But I'm not surprised. 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. 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>
<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>
<br>
</font></font>
<blockquote type="cite"
cite="mid:CAC20D2N2z04bq7n4We1s-E5GRfnssKsW1B4Kv_60SJTb1LHS0A@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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
face="arial, helvetica, sans-serif" color="#ff0000">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 face="arial, helvetica,
sans-serif" color="#ff0000"><br>
</font></div>
</div>
</div>
</div>
</blockquote>
<font color="#ff0000"><font face="arial, helvetica, sans-serif"><font
color="#000000">No clue. I had little contact with the Intel
(including ex-DEC) compiler folks when @INTC; I was trying to
overcome NIH in other arenas.</font></font></font><br>
<blockquote type="cite"
cite="mid:CAC20D2N2z04bq7n4We1s-E5GRfnssKsW1B4Kv_60SJTb1LHS0A@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#ff0000">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 face="arial, helvetica,
sans-serif" color="#ff0000"><br>
</font></div>
<div class="gmail_default"><font face="arial, helvetica,
sans-serif" color="#ff0000"><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"
moz-do-not-send="true"><font size="1" color="#ffffff">ᐧ</font></div>
</blockquote>
DEC had a long history (going back to the 36-bit world) of managing
& qualifying complex software dependencies. And the discipline
to pass the lessons along. .EXEs from VMS 1.0 run today - sharable
libraries included (no private versions necessary.)<br>
<br>
M$ did not have the history. The resulting "DLL HELL" and
"installation nightmares" are well known, and not resolved to this
day. (And don't get me started on the challenges of
uninstalling...)<br>
<br>
Linux is somewhat in the middle - the current container craze tries
to prevent interactions by - having private copies of sharable
libraries. So they're sharable, but not shared (outside each
container). And I'm tracking a project where some components
require Python 2 and others require Python 3 - in the same
container. So even the languages aren't upward compatible. But
RPMs and DEBs seem to have learned from setld (and VMSINSTAL/PCSI).
Unix sharable library versioning is capable of being sane - but to
the extent that there are standards, compliance is spotty. So
people give up and static link...<br>
<br>
INTC studied software development with M$, adopting its practices.
(Not necessarily its best ones.)<br>
<br>
Q.E.D.<br>
<br>
Was it admiral Nelson who observed that 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.<br>
<br>
Grump.<br>
<br>
</body>
</html>