[M3commit] CVS Update: cm3

[Rodney M. Bates]

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