Path: utzoo!attcan!uunet!tut.cis.ohio-state.edu!ucsd!network.ucsd.edu!celit!ps
From: ps@fps.com (Patricia Shanahan)
Newsgroups: comp.arch
Subject: Re: Vector_Assembly (was: It looks like he's at it again!)
Message-ID: <10009@celit.fps.com>
Date: 16 Jul 90 15:20:41 GMT
References: <1990Jul10.072443.4844@cs.UAlberta.CA> <63692@sgi.sgi.com> <9896@celit.fps.com> <1990Jul12.202223.17675@murdoch.acc.Virginia.EDU>
Sender: daemon@fps.com
Reply-To: ps@fps.com (Patricia Shanahan)
Distribution: comp.arch
Organization: FPS Computing Inc., San Diego CA
Lines: 33

In article <1990Jul12.202223.17675@murdoch.acc.Virginia.EDU> dwells@fits.cx.nrao.edu writes:

>You can count me on the side of those who think that HLL is generally
>the only approach that makes economic sense. However, I know of one
>important exception:
>				Vector CPUs
>
>Many vector CPUs have vector instructions that their compilers do not
>invoke. 

I found what seems to have been an effective compromise for these
situations for the FPS Model 500. I added to the code generator
support for a set of psuedo-call interfaces that give the C or
Fortran programmer full assembly language level control over the the
vector processor.

I originally intended it for my own use in getting some vector code
written for performance analysis before the vectorizing compiler was
available, but people have found other uses for it. It is a good
programming level for hand tuned versions of critical functions, both
FPS supplied and customer written. It gives access to all the vector
processor commands, including a few such as "population count" which
the compiler does not generate.

In many of these functions the performance is totally dominated by
the vector work. The effort of assembly language coding the scalar
code would be wasted.

--
	Patricia Shanahan
	ps@fps.com
        uucp : ucsd!celerity!ps
	phone: (619) 271-9940