<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>This is regarding <a class="moz-txt-link-freetext" href="https://dwarfstd.org/issues/250924.2.html">https://dwarfstd.org/issues/250924.2.html</a></p>
    <p>In a meeting today Cary made an offhand comment along the lines
      of "Do we need to add a remainder operator?" My initial thought
      was "no -- not without a compelling justification". Then someone
      hypothesized that the only reason DW_OP_mod even exists is to do
      address arithmetic. Thinking about this a bit more, I'm left
      unconvinced that DWARF actually needs an actual mathematical
      modulo operator but I can readily see that address arithmetic
      could certainly use a remainder operation. </p>
    <p>What do you guys think of this idea?</p>
    <p>In DWARF6 we rename DW_OP_mod to DW_op_remainder leaving
      DW_OP_mod an alias to DW_OP_remainder and then copy the semantics
      from the C standard. Where:<br>
    </p>
    <p>
      <li>It is only defined for integral types.</li>
      <li><span data-huuid="1780983847495272636"><span>The C standard
            (since C99) specifies that the result of <code
              class="mv6bHd">a % b</code> has the same sign as the
            dividend <code class="mv6bHd">a</code>.</span><span> </span></span></li>
      <li><span data-huuid="1780983847495272158"><span>The relationship
            between division and remainder is given by the equation: <code
              class="mv6bHd">(a / b) * b + (a % b) == a</code>.</span><span>
          </span></span><span data-huuid="1780983847495271919"><span>This
            holds true for both positive and negative values.</span><span>
          </span></span></li>
      <li><span data-huuid="1780983847495271441"><span>Integer division
            (<code class="mv6bHd">/</code>) in C performs truncation
            towards zero.</span></span></li>
    </p>
    <p>This way it can be easily implemented in consumers with the C "%"
      operator. This would also make it backwardly compatible with any
      current uses of DW_OP_mod for address arithmetic. Considering,
      Michael Eager's pronouncement more than a decade ago that
      DW_OP_mod is only defined for unsigned integral types, there
      should be no uses of the current DW_OP_mod that incompatible with
      this interpretation.</p>
    <p>If someone in the future does come up with a justification for a
      real mathematical modulo operator then we can add that to the
      DWARF standard giving it a name like DW_OP_modulo and then have a
      non-normative note saying "that DW_OP_modulo should not be
      confused with the historic alias for DW_OP_remainder  DW_OP_mod." </p>
    <p>This way we retain backward compatibility with the current
      interpretation of DW_OP_mod where it is defined only for unsigned
      integral types so that it can be used for address arithmetic
      without having to dive into the complexity of the mathematical
      modulo operator. In other words, this is the least work approach
      to resolving the issue.</p>
    <p>If this sounds like an acceptable approach, then I will rewrite 250924.2.html
      and forward it to Cary.</p>
    <p>-ben</p>
    <div class="moz-cite-prefix">On 9/24/25 4:46 PM, Ron Brender wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANSbVTiwPVu1XUU+tYkGkiQKXfPz0pH0Z+h7VbvutCTZV_RsOA@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">For starters, the proposed text is a non-starter
        (forgive the play on words)
        <div>because there is no Chapter 2 Section 4 in Knuth's The Art
          of Computer</div>
        <div>Programming Volume 1. Chapter 2 is entitled Information
          Structures, in which</div>
        <div>section 2.4 (is that what you mean by "Section 4"?) is
          entitled Multilinked</div>
        <div>Structures, and has nothing to do with the modulo
          operation.</div>
        <div><br>
        </div>
        <div>The discussion mentions Section 1.2.4, which is actually in
          Volume 1,</div>
        <div>Chapter 1, is entitled Integer Functions and Elementary
          Number Theory,</div>
        <div>and does define and discuss the modulo operation.</div>
        <div><br>
        </div>
        <div>Even if the citation were correct, I would object on the
          grounds that I believe</div>
        <div>the DWARF text should provide the definition, not a
          citation that the reader</div>
        <div>needs to consult. A footnote to an external source might be
          OK if there were</div>
        <div>complicated issues of possible supplementary interest.</div>
        <div><br>
        </div>
        <div>Finally, the Knuth definition is given in terms of real
          numbers, of which</div>
        <div>integers are a special case, using floor and ceiling
          operations. This </div>
        <div>would be appropriate if DWARF DW_OP_mod were intended to
          apply</div>
        <div>to floating-point operands but is rather pedantic overkill
          for just integers.</div>
        <div><br>
        </div>
        <div>But I think the real problem is not the definition of
          DW_OP_mod per se but</div>
        <div>the definition of the generic type. DWARF Section 2.5.2
          defines the generic</div>
        <div>type as an "integral type that has the size of an address
          on the target machine</div>
        <div>and unspecified signedness." We know that some
          architectures treat addresses</div>
        <div>as signed and some as unsigned integers, and DWARF is
          trying not to care.</div>
        <div><br>
        </div>
        <div>Most of the time it mostly doesn't matter. But to be
          concrete, what does one make of</div>
        <div><br>
        </div>
        <div>     DW_OP_lit5</div>
        <div>     DW_OP_lit2</div>
        <div>     DW_OP_neg</div>
        <div>     DW_OP_mod</div>
        <div><br>
        </div>
        <div>If the generic type is signed, then the result is -1.
          However, if the generic type</div>
        <div>is thought to be unsigned, then "-2" is just a very large
          positive number and</div>
        <div>the result is 5.</div>
        <div><br>
        </div>
        <div>We might think about solving this problem by defining the
          generic type to be</div>
        <div>     a) signed</div>
        <div>     b) unsigned</div>
        <div>     c) signedness implementation-defined</div>
        <div>I would not advocate either a) or b). Moreover, I would be
          very caution in overturning the</div>
        <div>"non-signedness" of generic type which has been
          characteristic of DWARF from the beginning</div>
        <div>(even before the name "generic type" was introduced).</div>
        <div><br>
        </div>
        <div>Defining DW_OP_mod to be defined only for unsigned integers
          seems</div>
        <div>overkill and unnecessary when no generic type operands are
          involved.</div>
        <div><br>
        </div>
        <div>A more permissive approach is to specify that an operand of
          the generic</div>
        <div>type is implicitly treated as unsigned. Then use the Knuth
          definition restricted to</div>
        <div>integers. This is close to Ben's second alternative but
          further resolves the ambiguity</div>
        <div>of generic signedness.</div>
        <div><br>
        </div>
        <div>Ben has raised a definite problem for which further thought
          is surely warranted...</div>
        <div><br>
        </div>
        <div>Ron</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
      </div>
      <br>
      <div class="gmail_quote gmail_quote_container">
        <div dir="ltr" class="gmail_attr">On Wed, Sep 24, 2025 at
          2:32 PM Ben Woodard via Dwarf-discuss <<a
            href="mailto:dwarf-discuss@lists.dwarfstd.org"
            moz-do-not-send="true" class="moz-txt-link-freetext">dwarf-discuss@lists.dwarfstd.org</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Background:<br>
          <br>
          Evidently, originally DWARF didn't allow arithmetic operations
          on <br>
          floating point numbers and most uses of the DWARF stack were
          done with <br>
          the assumption that the values being acted upon were addresses
          and so <br>
          the computation was assumed to be acting upon unsigned
          numbers.<br>
          <br>
          At some point, DWARF began to allow the arithmetic operations
          to work on <br>
          floating point numbers and several operations were explicitly
          defined to <br>
          work over non-integral values. This led to the paragraph in
          the current <br>
          DWARF working draft that says in section 2.5.2.4 on page 37
          lines 24-27:<br>
          <br>
          "Operations other than DW_OP_abs, DW_OP_div, DW_OP_minus,<br>
          DW_OP_mul, DW_OP_neg and DW_OP_plus require integral types of
          the<br>
          operand (either integral base type or the generic type).
          Operations do <br>
          not cause<br>
          an exception on overflow."<br>
          <br>
          Unlike all the other arithmetic operations this explicitly
          limits <br>
          DW_OP_mod to integral base types and the generic type. It
          lumps <br>
          DW_OP_mod in with the logical operations. Furthermore, there
          are <br>
          multiple definitions of the modulo operator which vary in how
          they <br>
          handle signed values.<br>
          <br>
          According to the dwarf-discuss archives, this issue came up
          back in 2011 <br>
          and at that time Michael Eager made a pronouncement that
          DW_OP_mod used <br>
          the modulo algorithm for unsigned arithmetic. However, this
          decision was <br>
          not recorded in the standard. Since that time, consumers have
          <br>
          implemented different implementations of DW_OP_mod.<br>
          <br>
          This proposal seeks to clarify and harmonize the consumer <br>
          implementations of the DW_OP_mod operator by defining which
          algorithm to <br>
          use for signed arithmetic as well as define it for floating
          point numbers.<br>
          <br>
          Proposal:<br>
          <br>
          Add DW_OP_mod to the list of operators which do not require
          integral <br>
          base types by changing:<br>
          <br>
          Operations other than DW_OP_abs, DW_OP_div, DW_OP_minus,
          DW_OP_mul, <br>
          DW_OP_neg and DW_OP_plus require integral types of the operand
          (either <br>
          integral base type or the generic type).<br>
          <br>
          To:<br>
          <br>
          Operations other than DW_OP_abs, DW_OP_div, DW_OP_mod,
          DW_OP_minus, <br>
          DW_OP_mul, DW_OP_neg and DW_OP_plus require integral types of
          the <br>
          operand (either integral base type or the generic type).<br>
          <br>
          Then append the following sentence to the description of the
          DW_OP_mod:<br>
          <br>
          The algorithm used to implement modulo shall be the one
          defined in The <br>
          Art of Computer Programming Volume 1: Fundamental Algorithms
          Chapter 2 <br>
          Section 4. Knuth.<br>
          <br>
          Alternative proposals:<br>
          <br>
          1) Explicitly state in the standard that DW_OP_mod is only
          defined for <br>
          unsigned integral arithmetic. This effectively standardizes
          the Michael <br>
          Eager's pronouncement from 2011.<br>
          <br>
          2) Pick any algorithm for modulo that works for signed as well
          unsigned <br>
          arithmetic and specify that DW_OP_modulo shall follow it. The
          current <br>
          GDB implementation follows Knuth 1.2.4 for signed and unsigned
          integral <br>
          arithmetic but excludes the algorithm for reals and floating
          point numbers.<br>
          <br>
          <br>
          -- <br>
          Dwarf-discuss mailing list<br>
          <a href="mailto:Dwarf-discuss@lists.dwarfstd.org"
            target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">Dwarf-discuss@lists.dwarfstd.org</a><br>
          <a
href="https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss"
            rel="noreferrer" target="_blank" moz-do-not-send="true"
            class="moz-txt-link-freetext">https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss</a><br>
        </blockquote>
      </div>
    </blockquote>
  </body>
</html>