Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!ux1.cso.uiuc.edu!aries!mcdonald
From: mcdonald@aries.scs.uiuc.edu (Doug McDonald)
Newsgroups: comp.arch
Subject: Re: Integer Multiply/Divide on Sparc
Message-ID: <1990Jan1.155349.9105@ux1.cso.uiuc.edu>
Date: 1 Jan 90 15:53:49 GMT
References: <84768@linus.UUCP> <8840004@hpfcso.HP.COM> <1804@l.cc.purdue.edu> <1535@cbnewsi.ATT.COM> <28548@amdcad.AMD.COM> <1989Dec30.161619.22893@phri.nyu.edu> <1296@quintus.UUCP>
Sender: news@ux1.cso.uiuc.edu (News)
Organization: Univ. of Illinois at Urbana-Champaign, Chemical Sciences
Lines: 35

In article <1296@quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
>In article <1989Dec30.161619.22893@phri.nyu.edu> roy@phri.nyu.edu (Roy Smith) writes:
>>                                                        Most (handwave)
>>non-computational integer multiplies (by which I mean operations invented by
>>the compiler for array subscripting, pointer arithmetic, etc) involve one
>>constant factor with few ones, ideal for shift-and-add strength reductions.
>
>Roy Smith isn't the only one to say this recently in comp.arch.
>What I'm afraid of here is the coupling I see between RISC design and
>crippled programming languages.  Smith's claim about array subscripting
>is true in some pathetically crippled languages where array bounds are
>completely known at compile time (C and Pascal, and some derivatives of
>Pascal).  It wasn't true in Algol 60 or Simula 67, and it isn't true in
>Fortran 77.

>Actually, there _is_ a way that addressing polynomials could be handled
>efficiently on machines which have slow multiplication, and that is for
>a dynamic array declaration like
>	real array a[1:P,1:Q,1:R];
>to generate a local "addressing subroutine" at _run_ time
>using whatever multiply-step sequence was best.  But that, of course,
>requires a cheap way of generating code on the run.  And there are some
>RISC systems that make _that_ hard too.
>

These are two interesting and important points. Especially the latter one:
some machine architectures may NEED the ability to use self-modifying
code to get good speed. 

********This should be the subject of an entire new flame-thread. I
have found that architectures (or OS's) that don't allow EASY 
self-modifying code (or for most of my stuff, incremental compilation)
are sufficiently brain-dead to be unuseable for many purposes.*****

Doug McDonald (mcdonald@aries.scs.uiuc.edu)