[M3commit] CVS Update: cm3

[Jay K]

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.
 
 
 
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..)
>>
>>