<!DOCTYPE html>
<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    (Let me try sending this again, now that I'm a member of the list.)<br>
    <br>
    Another example of operator-typing in BLISS, of more use in a kernel
    than floating point, is in the relational operators.  For example,
    GTR (greater-than) for signed comparison, GTRU for unsigned
    comparison, and GTRA for address comparison (where the number of
    bits in an address is less than the number of bits in a machine
    word), etc. for the other 5 relations.
    <div class="moz-forward-container"> <br>
      <div class="moz-cite-prefix">On 7/9/24 13:18, Paul Winalski wrote:<br>
      </div>
      <blockquote type="cite"
cite="mid:CABH=_VRbhCq=hD+OhtQkn7+eb2rzOe43BVqi=7wSZjfWr3puqQ@mail.gmail.com">
        <meta http-equiv="content-type"
          content="text/html; charset=UTF-8">
        <div dir="ltr">
          <div class="gmail_quote">
            <div> expression-1<offset-expr, size-expr,
              padding-expr></div>
            [...] padding-expr controls the value used to pad the high
            order bits:  if even, zero-padded, if odd, one-padded.
            <div><br>
            </div>
            <div>I always wondered how this would work on the IBM
              S/360/370 architecture.  It is big-endian and bit 0 of a
              machine word is the most significant bit, not the least
              significant as in DEC's architectures.</div>
          </div>
        </div>
      </blockquote>
      <br>
      Offset and Size taken as numbers of bits in a value (machine
      word), not bit numbers, works just fine for any architecture.  The
      PDP-10 and other DEC architectures before the PDP-11 were
      word-addressed with bit 0 at the high-order end.<br>
      <br>
      The optional 3rd parameter is actually 0 for unsigned (zero)
      extension and 1 for signed (highest order bit in the extracted
      field) extension.  I don't think signed extension is widely used,
      but it depends on the data structure you're using.<br>
      <br>
      When verifying that, I found something I did not remember, that in
      BLISS-16 and -32 (and I would guess also -64), but not -36 (the
      word-addressed PDP-10), one could declare 8-bit signed and
      unsigned data:<br>
      <blockquote>OWN<br>
            X: BYTE SIGNED,<br>
            Y: BYTE;<br>
      </blockquote>
      So the concepts of 'type' in BLISS, at least regarding data size
      and representation, can get a little complicated (not to be
      confused with COMPLEX :-) ).<br>
      <br>
      --------<br>
      <br>
      An aside re: bit twiddling from CMU and hardware description
      languages:<br>
      <br>
      Note that the ISP/ISPL/ISPS machine description language(s) from
      books by Gordon Bell et al. used the following syntax for a bit or
      a bit field of a register:<br>
      <blockquote>REG<BIT_NR><br>
        REG<HIGH_BIT_<a class="moz-txt-link-freetext" href="NR:LOW_BIT_NR">NR:LOW_BIT_NR</a>><br>
        REG<BIT_NR,BIT_NR,...><br>
      </blockquote>
      (',...' is meta syntax.)  Sign extension was handled by a unary
      operator because the data were all bit vectors, instead of values
      as in BLISS, so the width (in bits) of an expression was known. 
      The DECSIM logic simulator inherited this syntax.  Brackets were
      used for memory addresses, so you might have M[0]<0:2> for
      the first 4 bits of the first word in memory.  I still find it the
      most clear syntax, but then it is what I used for many years. 
      (Sorry, VHDL and Verilog, although you won due to the idea back in
      the day that internally-developed VLSI CAD software was to be kept
      internal.)<br>
      <br>
      - Aron<br>
      <br>
    </div>
  </body>
</html>