Xref: utzoo comp.arch:10550 comp.lang.misc:3052
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!dik
From: dik@cwi.nl (Dik T. Winter)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Double Width Integer Multiplication and Division
Message-ID: <8257@boring.cwi.nl>
Date: 7 Jul 89 23:53:14 GMT
References: <57125@linus.UUCP> <1989Jun24.230056.27774@utzoo.uucp> <13961@haddock.ima.isc.com> <1395@l.cc.purdue.edu> <13970@haddock.ima.isc.com>
Organization: CWI, Amsterdam
Lines: 44

Note also the reply why it is difficult to define syntax/semantics in
article <4909@ficc.uu.net> by peter@ficc.uu.net (Peter da Silva) and
the excellent explanation why MIPS does not provide a double width by
single width division in article <4016@bauhaus.NeXT.UUCP> by
chansen@NeXT.UUCP (Craig Hansen).  And I would also like to have
the double width operations directly visible, but I think it is more
difficult than Herman Rubin envisages.  In my opinion the gcc solution,
where you can use your own variables in asm statements, looks best.

A correction to the next statement:
In article <13970@haddock.ima.isc.com> suitti@haddock.ima.isc.com (Stephen Uitti) writes:
 > The code sequence is:
[a routine to add two vectors, using pointers]
 > or:
[an alternative]
 > A '205 C compiler should (doesn't but should) take either
 > piece of code and translate it into the instruction.
This is not true.  Because 'noalias' is out, the compiler has no knowledge
whether the sources overlap the destination.  So a lot more has to be done.
Unless the compiler is willing to do inlining, in which case it might (but
need not) have knowledge about overlap.

Another remark from the same article:
 > >I consider the 205 hardware the best designed vector hardware I have
 > >seen.
 > 
 > No real debate here.  The '205 was a real ambitious project.
 > Very, very difficult and costly to maintain, but real nice.
Some debate here (or simply, I do not agree).  However, the real problem
with the 205 is the abominable compiler.  Architecture is not really an
issue here; given a good compiler it would perform well.  Given the
compiler it has you have a heavy task to get acceptable performance.

On to the RISC vs. CISC debate:  how many of the 60000+ instructions
of the 205 do you think are ever used?  I know quite a lot that are
never used unless you use 'special calls', which is nothing more than
'asm' in C.

For discussions about the 205 hardware please follow up with a
different subject, or do it by mail.
-- 
dik t. winter, cwi, amsterdam, nederland
INTERNET   : dik@cwi.nl
BITNET/EARN: dik@mcvax