[M3commit] CVS Update: cm3

[Tony Hosking]

On 21 Jun 2010, at 21:32, Jay K wrote:

> 
> I researched this -- searched the web, read Wikipedia, etc..I realize that calling "research" may be an exaggeration.
> There are approximately four reasonable definitions of div and mod for negative numbers.
> 
> 
> The most important thing is that div and mod are defined in terms of each other, in all variations, but that doesn't actually pin it down.
> 
> 
> There is round up (toward positive infinity), round down (toward negative infinity), toward 0 (truncation), there is Euclidean way.
> 
> 
> One might expect n mod m to be in the range [0,m), or perhaps the absolute value to be in [0,m), but I think Modula-3 doesn't make that so. It is surprising imho for mod to be outside that range.
> 
> 
> 
> C89 left it undefined. So implementor could pick whatever was fastest/easiest.
> Fortran specified truncation. Nobody complained.
> C99 adopted Fortran's definition.
> So it is well defined now.
> Negative numbers are overused anyway.
> Everyone defines it the same for positive numbers, and that's generally sufficient anyway.

But not if you can index arrays using negative indexes as in Modula-3.  C, Fortran, etc. don't have this feature so they can get it wrong and nobody will notice.


> 
> 
> 
> As well C's ldiv function was explicitly defined to be truncating and therefore portable.
> 
> 
> 
> (Notice that Modula-3's implementation was long broken for other reasons as well: It dependended on silent overflow, which gcc can warn about and break, and it didn't work for maximum/minimal numbers.)
> 
> 
> - Jay
> 
> 
> ----------------------------------------
>> Date: Mon, 21 Jun 2010 20:07:04 -0500
>> From: rodney_bates at lcwb.coop
>> To: m3commit at elegosoft.com
>> Subject: Re: [M3commit] CVS Update: cm3
>> 
>> 
>> 
>> Jay Krell wrote:
>>> CVSROOT: /usr/cvs
>>> Changes by: jkrell at birch. 10/06/21 08:12:11
>>> 
>>> Modified files:
>>> cm3/m3-sys/m3cc/gcc/gcc/config/arm/: arm.h
>>> cm3/m3-sys/m3cc/gcc/gcc/m3cg/: parse.c
>>> 
>>> Log message:
>>> put div/mod back to long standing and release form:
>>> almost always call a function, unless both parameters known
>>> to be positive or the type is unsigned
>>> 
>>> Modula-3 very unfortunately defines div/mod differently than
>>> pretty much everyone else. Perhaps perhaps the language
>>> definition can be repaired.
>> 
>> No, the language is correct. This is the mathematically correct definition
>> of mod/div. We can be thankful that at least one language actually got it
>> right. Moreover, the mathematicians knew what they were doing. Try some
>> example coding with, e.g., arrays as circular buffers, using mod/div to
>> increment/decrement your way around them. So many times in other languages,
>> I have struggled with the frustration of having to write overcomplicated code
>> to compensate for incorrect mod/div in other than the first quadrant.
>> 
>> C is particularly exasperating, because it doesn't define them at all outside
>> the first quadrant. It is implementor's option. This means these operators
>> are entirely unusable for code that needs to be the least bit portable--even
>> different compilers on the same machine. You always have to adjust your
>> operands to first quadrant, do the operation, and then readjust.
>> 
>> In Modula-3, you just do the operation.
>> 
>> It turns out there are several
>>> reasonable definitions of div and mod. Modula-3 doesn't
>>> chose the obvious correct one and C doesn't chose the
>>> obvious incorrect one.
>>> 
>>> We may yet be able to use the gcc support but it makes me nervous.
>>> It requires at least in a very minimal sense, for the frontend
>>> to support TImode (aka int128_t).
>>> 
>>> See: http://gcc.gnu.org/ml/gcc/2010-06/msg00647.html
>>> (which is just from me, talking to myself..)
>>> 
>>>