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)