Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site ccvaxa
Path: utzoo!watmath!clyde!cbosgd!ihnp4!inuxc!pur-ee!uiucdcs!ccvaxa!aglew
From: aglew@ccvaxa.UUCP
Newsgroups: net.arch
Subject: Re: Integer division
Message-ID: <5100003@ccvaxa>
Date: Wed, 5-Feb-86 22:33:00 EST
Article-I.D.: ccvaxa.5100003
Posted: Wed Feb  5 22:33:00 1986
Date-Received: Fri, 7-Feb-86 20:57:23 EST
References: <11610@ucbvax.BERKELEY.EDU>
Lines: 24
Nf-ID: #R:ucbvax.BERKELEY.EDU:11610:ccvaxa:5100003:000:991
Nf-From: ccvaxa.UUCP!aglew    Feb  5 21:33:00 1986


I just thought that it might be worthwhile pointing out that
what people are arguing about is not an architectural issue
but a linguistic issue. If you are annoyed that you have to
write something stupid like

	a = b % c;
	if( a < 0 ) a += c;

because of the way your math library does % (call it modulo,
call it remainder - I don't care) then you can always define
it as a function, say, a = positive_mod(b,c).
	Don't like that? Then what you want is a language that
lets you define your own infix operators. Try Ada.

The only architectural question here is - what should the
actual hardware support, if it has a MOD instruction?
I don't think that there are any hardware issues here
- I don't know of any circuits that do a good job of
implementing an arbitrary MOD - and, unfortunately, under
neither scheme could we get away with only one instruction for
both signed and unsigned arithmetic. Have I missed anything?
And, please, let us talk about architecture, not interior
decorating.