This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Comments on the suggestion to use infinite precision math for wide int.

On 04/08/2013 04:56 AM, Florian Weimer wrote:
On 04/07/2013 07:16 PM, Kenneth Zadeck wrote:
The poster child for operations that do not belong to a ring is division.
For my example, I am using 4 bit integers because it makes the
examples easy, but similar examples exist for any fixed precision.

Consider 8 * 10 / 4

in an infinite precision world the result is 20, but in a 4 bit
precision world the answer is 0.

I think you mean "4" instead of "20".

another example is to ask if

-10 * 10 is less than 0?

again you get a different answer with infinite precision.

Actually, for C/C++ ,you don't—because of undefined signed overflow
(at least with default compiler flags). But similar examples with unsigned types exist, so this point isn't too relevant.

I would argue
that if i declare a variable of type uint32 and scale my examples i have
the right to expect the compiler to produce the same result as the
machine would.

In my very, very limited experience, the signed/unsigned mismatch is more confusing. With infinite precision, this confusion would not arise (but adjustment would be needed to get limited-precision results, as you write). With finite precision, you either need separate types for signed/unsigned, or separate operations.

I come from a world where people write code where they expect full control of the horizon and vertical when they program. Hank Warren, the author of Hacker Delight is in my group and a huge number of those tricks require understanding what is going on in the machine. If the compiler decides that it wants to do things differently, you are dead.
While C and C++ may have enough wiggle room in their standards so that
this is just an unexpected, but legal, result as opposed to being wrong,
everyone will hate you (us) if we do this.  Furthermore, Java explicitly
not allow this (not that anyone actually uses gcj).  I do not know
enough about go,

Go specified two's-complement signed arithmetic and does not automatically promote to int (i.e., it performs arithmetic in the type, and mixed arguments are not supported).

Go constant arithmetic is infinite precision.

> ada and fortran to say how it would effect them.

Ada requires trapping arithmetic for signed integers. Currently, this is implemented in the front end. Arithmetic happens in the base range of a type (which is symmetric around zero and chosen to correspond to a machine type). Ada allows omitting intermediate overflow checks as long as you produce the infinite precision result (or raise an overflow exception).

I think this applies to Ada constant arithmetic as well.

(GNAT has a mode where comparisons are computed with infinite precision, which is extremely useful for writing bounds checking code.)

Considering the range of different arithmetic operations we need to support, I'm not convinced that the ring model is appropriate.

I will answer this in Robert's email.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]