<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 26-Jan-18 14:09, Clem Cole wrote:<br>
<blockquote type="cite"
cite="mid:CAC20D2P5BS3QGR1UNnv+-EDMEzUJZwNJiZ6z4dP5mJQ8-qyNrw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote"><br>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif">The other thing to
add is there were at least two generations of the
compilers within DEC that I knew about. </font></font></div>
</div>
</div>
</div>
</blockquote>
<font color="#0000ff"><font face="arial, helvetica, sans-serif">Yes.
</font></font><br>
<blockquote type="cite"
cite="mid:CAC20D2P5BS3QGR1UNnv+-EDMEzUJZwNJiZ6z4dP5mJQ8-qyNrw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif">Tim you may have
know of a third when I was off doing other things.
The last (current) is the 'Gem' compilers which was a
rewrite to allow N font-ends, with Y back-ends. I
thought 'Compatible BLISS' was done to create
BLISS-36/16/32 (PDP-10, 11, Vax) from the original CMU
base; but was only targeting BLISS. <br>
</font></font></div>
</div>
</div>
</div>
</blockquote>
<font color="#0000ff"><font face="arial, helvetica, sans-serif">Yes
- "Common BLISS", not "compatible". But Common BLISS also
included a lot of language changes.<br>
<br>
</font></font>
<blockquote type="cite"
cite="mid:CAC20D2P5BS3QGR1UNnv+-EDMEzUJZwNJiZ6z4dP5mJQ8-qyNrw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif"> AFAIK, the
original Compatible BLISS compiler was developed on
the PDP-10 and eventually replaced the CMU code. </font></font></div>
</div>
</div>
</div>
</blockquote>
<font color="#0000ff"><font face="arial, helvetica, sans-serif">Yes
- VMS was initially developed under TOPS-20 with the cross
tools. The developers were happy when it became self-hosted on
the VAX, though they lost a lot in moving from a mature
environment. But pride of self covers a lot of pain.<br>
<br>
The LCG products moved to Common BLISS - FORTRAN, RMS, APL
perhaps the most notable. One or two might have been left
behind because they were so stable. But none come immediately
to mind.<br>
<br>
</font></font>
<blockquote type="cite"
cite="mid:CAC20D2P5BS3QGR1UNnv+-EDMEzUJZwNJiZ6z4dP5mJQ8-qyNrw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif">Prism forced the
rewrite of the back-ends and with it the later
generation and TLG wanted to clean up its act with a
single back-end/optimizer that was common for all the
languages [hence the Gem project - I'd have to ask
Rich Grove for the details]. IIRC, Vax was used as
the base for that system, although it moved to Alpha
by the mid/late 1990s.</font></font></div>
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif"><br>
</font></font></div>
</div>
</div>
</div>
</blockquote>
<font color="#0000ff"><font face="arial, helvetica, sans-serif">Sounds
right. The -16 and -36 versions stayed with the native backend
and didn't get much attention once GEM took off. At least, I
don't recall GEM support for them. However, there was minimal
change to the language, so Common BLISS remained common. (I
think the changes were stuff like architecture-specific PSECT
attributes, alignments & builtins.) GEM was very successful
in consolidating optimization efforts across all the languages.
It also made it feasible to add object code generation for
various runtime environments for multiple languages. Turned an
n * m problem into essentially n + m.<br>
<br>
Alpha pretty much repeated the VAX route (plus the stupid
mistake of splitting the VMS sources). It cross-compiled from
VAX to simulation, then the internal early development alpha
subset hardware, then alpha. But it was a lot easier, since we
had real networks and cross-architecture clusters; you could
compile on a VAX, dismount the disk, and boot on an Alpha ADU in
about 30 seconds; later, compile on a VAX and run user mode on
Alpha without dismounting. OSF/1 was another story; I wasn't
involved in that.<br>
<br>
Because of GEM, compiler "generation" gets a bit fuzzy - updates
give BLISS new optimizations and targets (some radically
different), but (almost) all the work is in GEM, not the front
end. But GEM would race along for a while, but not be
incorporated into the released languages until there was some
forcing function. That could be a long time for BLISS, but not
so long for FORTRAN and C. So it depends on where you draw the
line - is GEM part of the compiler, or not? No doubt the
compiler guys can point to examples where GEM changes affected
the language front ends, but from afar it seemed a pretty stable
interface. 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. But I suspect there was
marketing (and qualification) pull toward hiding the boundaries
when packaging. After all, some 3rd party might have written a
backend for a non-DEC architecture.<br>
<br>
All three (CMU ,BLISS, GEM) back ends used considerable
creativity in interpreting the instruction sets, and as time
went on gave hand-coded assembler a run for its money. They
especially liked to do computations with bizarre-looking address
calculations. (Not all of which ran fast on all processors.)
In one case, a particularly "clever" encoding of a test on a
link-time constant broke RMS on an unreleased VAX CPU.
Interestingly, this one instruction was the ONLY time this
construct was encountered in all of VMS (including the top dozen
layered products), so waiting for the hardware spin wasn't as
bad as it might have been.<br>
<br>
Every time I do handstands with C #if/#define I still wish for
BLISS %if and %macro. (I once had to port a few 100K lines of
my BLISS code to C on a 68000, and even with automation,
converting macros and keyword initialized data structures to C
was a painful exercise in devolution by obfuscation...)<br>
<br>
<br>
</font></font>
<blockquote type="cite"
cite="mid:CAC20D2P5BS3QGR1UNnv+-EDMEzUJZwNJiZ6z4dP5mJQ8-qyNrw@mail.gmail.com">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div class="gmail_default"><font color="#0000ff"><font
face="arial, helvetica, sans-serif">Clem</font></font></div>
</div>
<br>
</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=757aa32f-fd01-4cc1-bcab-231a1e851823"
moz-do-not-send="true"><font size="1" color="#ffffff">ᐧ</font></div>
</blockquote>
<br>
</body>
</html>