<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>On 1/26/2018 3:28 PM, Timothe Litt wrote:<br>
    </p>
    <blockquote type="cite"
      cite="mid:21a9b029-9330-7cbf-220e-7b1e804d7a93@ieee.org"><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. <br>
        </font></font></blockquote>
    <br>
    I believe that's correct.<br>
    <br>
    <blockquote type="cite"
      cite="mid:21a9b029-9330-7cbf-220e-7b1e804d7a93@ieee.org"><font
        color="#0000ff"><font face="arial, helvetica, sans-serif">Alpha
          pretty much repeated the VAX route (plus the stupid mistake of
          splitting the VMS sources).  It cross-compiled from VAX to
          simulation,</font></font></blockquote>
    <br>
    I was porting a lot of freeware from VAX to Alpha when all that was
    available were the cross-compilers. The BLISS cross-compiler was
    great, but the early C cross-compilers were more problematic.<br>
    <br>
    <blockquote type="cite"
      cite="mid:21a9b029-9330-7cbf-220e-7b1e804d7a93@ieee.org"><font
        color="#0000ff"><font face="arial, helvetica, sans-serif">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>
        </font></font></blockquote>
    <br>
    <font color="#0000ff"><font face="arial, helvetica, sans-serif"><font
          color="#000000">I vaguely remember hearing about that.<br>
          <br>
        </font></font></font>BLISS-32 on VAX generated some amazing
    optimizations. Before I got into BLISS, I programmed almost
    exclusively in MACRO-32, and it was fun to compare code I wrote to
    the assembly code generated by the BLISS compiler. Several times, I
    encountered generated code that was a lot more efficient than the
    code I wrote, which I thought was very efficient. I learned a few
    MACRO tricks looking at the code generated. It was less fun trying
    to understand the GEM output for Alpha. ;-)<br>
    <br>
    <blockquote type="cite"
      cite="mid:21a9b029-9330-7cbf-220e-7b1e804d7a93@ieee.org"><font
        color="#0000ff"><font face="arial, helvetica, sans-serif"> 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>
        </font></font></blockquote>
    <br>
    Yes, the BLISS macros and lexicals are awesome, and it also kills me
    that C never had them.<br>
    <br>
    Hunter<br>
    <br>
  </body>
</html>