<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 26-Jan-18 14:45, Paul Koning wrote:<br>

    </div>

    <blockquote type="cite"

      cite="mid:3887FBE5-BCB4-43BB-8895-0CB11DFE961A@comcast.net">

      <pre wrap="">ent.  I also do not know what they are doing with the front-ends.  

</pre>

      <pre wrap="">

One of the more curious front ends of GEM is the Alpha assembler.  I found out about that when doing some Alpha hand-optimizing early on (a handcoded "memcpy with TCP checksum calculation while doing it" if I remember right).  It turned out I could write drafts of that code and give it to the assembler with a /OPTIMIZE switch to let the back end take what I wrote and do stuff to it.  It wasn't always right, but it was a neat source of ideas.

</pre>

    </blockquote>

    Well, not exactly an optimizing assembler.  It sort of looks like

    one.  But the real story is that the Alpha port needed to deal with

    the large amount of MACRO-32 in VMS.  The solution was to treat

    MACRO-32 as a compiled language, and generate a GEM front end for

    it.  There was a lot of optimization that was absolutely required if

    you wanted tolerable code - e.g. most VAX instructions set condition

    codes, but they are rarely tested - and when tested, usually only a

    subset of those set are involved in the test.  So tracking condition

    code generation and consumption is a big win.  And when you look at

    address generation, there's a lot of opportunity for CSE

    elimination, and other optimizations.  Then you wanted to schedule

    the generated code for Alpha - which is a lot of re-ordering,

    packing & the like.<br>

    <br>

    Then it was extended for the Alpha instruction set (psect

    attributes, instructions, etc).<br>

    <br>

    At this point, you have a compiler for low level language, that

    happens to look like assembler.  Externally, perhaps a distinction

    without a difference; internally, quite different.  And if you're

    unlucky enough to have to do instruction level debug, very different

    from traditional assembler.<br>

    <br>

    There also was the argument that you really couldn't (well,

    shouldn't) write pure assembler for Alpha because the best

    scheduling depends on the implementation (how many execution units,

    of what sorts & latencies; predictions, speculations, prefetch;

    etc.)<br>

    <br>

    PALcode has some unique constraints that do require manual

    scheduling, as do some diagnostics.  But it does turn out to be true

    that Alpha assembler is best understood (and used) as a low-level

    compiled language, not an assembler.<br>

    <br>

    <blockquote type="cite"

      cite="mid:3887FBE5-BCB4-43BB-8895-0CB11DFE961A@comcast.net">

      <pre wrap="">

The only other optimizing assembler I can think of is SOAP, way back in the 1950s.

        paul

</pre>

    </blockquote>

    <br>

  </body>

</html>