<div dir="ltr"><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px">"I am either too young or have lived a too sheltered life to be aware of any architectures which actually have signed addressing."<br><br></blockquote>Yes, those of us who grew up in computing using PDP-11, VAX and Alpha architectures, especially with the VMS operating system, learned to know and love (or at least make peace with) signed addresses. (And also stacks that grow downward -- but that is a different issue!:-) <div><br></div><div>Researching some more, my eyes were greatly opened and my mind greatly boggled by the article "Modulo" in Wikipedia (see</div><div><a href="https://en.wikipedia.org/wiki/Modulo">https://en.wikipedia.org/wiki/Modulo</a>). Among other things, that article ends with a table of 150 or more programming languages together with which of the <u><b>four</b></u> major versions of modulo it uses (Euclidean, Truncated, Rounded and Floored (this last includes Knuth)). A casual visual scan of that table suggests that no single one of the four dominates the others in frequency of occurrence. [A couple languages even leave the matter undefined or implementation-defined.]</div><div><br></div><div>My latest thoughts...</div><div><br></div><div><u>First</u>, this article absolutely must be at least cited in any discussion in any Issue proposal we might consider. There is a huge amount of information in it that should be taken into account.</div><div><br></div><div><u>Second</u>, I conclude that any single choice that DWARF might make would be a terrible choice for most languages. I think that DWARF should specify that the definition of modulo uses the definition for the language that applies in its execution context. I think I saw that GDB does this already so this is not a novel, never-been-tried idea.</div><div><br></div><div>If we do that, then applicability to floating-point types is also naturally left as language-dependent.</div><div><br></div><div>An alternative might be to replace the current modulo operator with four new operators, one for each of the four kinds of modulo mentioned above. I don't really like this idea but I think it is defensible.</div><div><br></div><div><u>Third</u>, the generic type is still a problem. Since the generic type is DWARFs invention it is DWARF's problem to solve I guess. So far my best suggestion is to say that an operand of the modulo operation whose type is generic is treated by that operator as an unsigned integer. I think that is the more common case and more consistent with our historical (if unpublished) position. [I prefer to keep this resolution specific to the modulo operator if possible and not venture into broader consideration of the nature of the generic type generally.]</div><div><br></div><div>Ron</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 9:03 PM Ben Woodard <<a href="mailto:woodard@redhat.com">woodard@redhat.com</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"><u></u>
<div>
<p><br>
</p>
<div>On 9/24/25 4:46 PM, Ron Brender wrote:<br>
</div>
<blockquote type="cite">
<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>
</blockquote>
I can correct that. When we were discussing the issue, Cary pulled
out his copy Knuth, mine is tucked away in a box that never got
unpacked the last time that I moved. I misunderstood his citation.
<blockquote type="cite">
<div dir="ltr">
<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>
</blockquote>
<p>I was kind of hoping that the dwarf-discuss community could
propose what they think it should be and then I'll be happy to
write that into the text of the proposal. I really don't have a
strong opinion on the matter.</p>
<p>I just think that whatever the algorithm is, it should be in the
standard. Right now we have:<br>
1) GDB implmenting, Knuth's algorithm but limited to signed and
unsigned integers. <br>
2) IIUC John DelSignore said TotalView implements DW_OP_mod using
C's % operator.<br>
3) and we have an email from Michael Eager from 2011 saying that
DW_OP_mod should only apply to unsigned integral types.</p>
<p>Let's all just get on the same page. (I don't care what page it
is.)</p>
<blockquote type="cite">
<div dir="ltr">
<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>
</blockquote>
<p>Yeah but in that section we have two broad classes of operators
arithmetic and logical. All the other arithmetic operators are
defined with a domain that includes non-integral types. Should we
exclude this one arithmetic operator from that more expansive
range?</p>
<p>It is not as if the algorithm is unknown or particularly
complicated.</p>
<p><em>x</em> mod <em>y</em> = <em>x</em> − <em>y</em> × floor(<em>x</em>
/ <em>y</em>), if <em>y</em> ≠ 0; <em>x</em> mod 0 = <em>x</em>.</p>
<blockquote type="cite">
<div dir="ltr">
<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>
</blockquote>
<p>exactly!</p>
<blockquote type="cite">
<div dir="ltr">
<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>
</blockquote>
<p>I am either too young or have lived a too sheltered life to be
aware of any architectures which actually have signed addressing.
I've seen plenty of cases where there are signed offsets added to
unsigned addresses to make unsigned addresses. This address
arithmetic avoids the complication of mixed signed and unsigned
arithmetic which can slip into naively written C code.</p>
<p>It seems to me that what you are really wanting with the generic
type is "address arithmetic" where you can do "unsigned_address +
signed_offset" and not have to worry about the C rules that can
cause mixed unsigned and signed arithmetic to yield unexpected
results. For example I believe that "unsigned_address +
signed_offset" is actually defined to be "unsigned_address +
(unsigned) signed_offset" causing a a very large unsigned value to
be added to the unsigned address in the case where signed_offset
happens to be a small negative.</p>
<p>I think that both "signed" and "unsigned" are kind of C concepts
and I would suggest that an other option which may provide a way
out of this dilemma is:<br>
</p>
<p>d) the generic type is a type is defined to be an integral type
suitable for address arithmetic.</p>
<p>and more specifically this means that when implementing a
consumer in C you must be careful when mixing signed and unsigned
values doing something like:<br>
</p>
<p>if (signed_offset >=0 ) <br>
unsigned_address+=signed_offset;<br>
else <br>
unsigned_address-=abs(signed_offset);</p>
<p>There may be other cases where the arithmetic of the "generic
type" diverges from integers in C or other language in subtle
ways. DW_OP_mod may be one of those but I haven't thought about it
enough to be sure.</p>
<p>-ben</p>
<p> </p>
<blockquote type="cite">
<div dir="ltr">
<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">
<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" target="_blank">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">Dwarf-discuss@lists.dwarfstd.org</a><br>
<a href="https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss" rel="noreferrer" target="_blank">https://lists.dwarfstd.org/mailman/listinfo/dwarf-discuss</a><br>
</blockquote>
</div>
</blockquote>
</div>
</blockquote></div>