Path: utzoo!attcan!uunet!husc6!bloom-beacon!bu-cs!purdue!i.cc.purdue.edu!k.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Vectorising conditional code.
Summary: A suggestion of for new types
Message-ID: <837@l.cc.purdue.edu>
Date: 17 Jul 88 18:56:17 GMT
References: <893@garth.UUCP> <28200176@urbsdc> <963@garth.UUCP> <7584@boring.cwi.nl>
Organization: Purdue University Statistics Department
Lines: 36

In article <7584@boring.cwi.nl>, dik@cwi.nl (Dik T. Winter) writes:
> In article <963@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
>  > >                                  How good are available
>  > >compilers at vectorizing complex arithmetic? Do people short
>  > >shrift complex because most "important" programs have already
>  > >been translated to use reals? Is this a self-fulfilling prophecy?
>  > 
>  > On the 205, complex is vectorised but into library calls. Vector complex
>  > operators require multiple scratch vectors and the code generator is
>  > only set up to define one scratch vector per operator. (Modular code?
>  > We don't need no steenking modular code.)
> 
> And we might want some better library routines.  Complex on the 205 is
> much slower than it needs to be.

The present types of complex and also of multiple, but fixed, precision where
the hardware does not already handle the precision (i.e, the double precision
on machines such as the VAX etc. for which operations on double precision
quantities are hardware operations do not qualify as multiple precision) could
be better handled if we used an array of vectors.

For example, suppose that the present procedure to deal with double precision
comples numbers is to have a vector DC in which each item is four machine
words, and the vector operations can do such things as compute both the
upper and lower parts of a double precision operation on two words.  Then
we should have four vectors, say RU (the upper part of the real part), RL,
CU, and CL.  This way it would not be necessary to set up the scratch vectors 
and to start out by separating the DC vector into the four parts, which we
are likely to have to do anyhow!

Other than the changes in the languages needed to accomplish this, I see little
problem except for input and output, and possibly the concatenation of vectors.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)