dwells@fits.acc.Virginia.EDU (Don Wells) (07/13/90)
In article <9896@celit.fps.com> dave@fps.com (Dave Smith) writes: >In article <63692@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes: > >In article <1990Jul10.072443.4844@cs.UAlberta.CA> cdshaw@cs.UAlberta.CA (Chris Shaw) writes: > >>The basic problem with assembly coding by hand vs assembly coding by compiler > >>is that IT DOESN'T SCALE. There are extremely limited application areas where > >>coding by hand is much faster.... Some examples: > > Graphics Rendering Seismic Deconvolution Audio Signal Processing... >David L. Smith>FPS Computing, San Diego>ucsd!celerity!dave or dave@fps.com 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. A notable example is the vector compress. In some cases, usually various forms of IFs in loops, the compilers do not take advantage of the instruction set and produce code that can be easily beaten by use of assembly language. Of course the real problem is weakness in the compilers: the best vectorizing compilers *do* utilize these instructions for IF-loops and, when doing so, can generally beat hand-coding. There will still remain a *small* (N-->0 as limit) group of bit-smashing applications where one occasionally will find that hand-coded vector instructions will beat the compiler... Donald C. Wells, Associate Scientist | NSFnet: dwells@nrao.edu [192.33.115.2] National Radio Astronomy Observatory | SPAN: NRAO::DWELLS [6654::] Edgemont Road | BITnet: DWELLS@NRAO Charlottesville, VA 22903-2475 USA | UUCP: ...!uunet!nrao.edu!dwells Lat: 38:02.2N Long: 78:31.1W | Tel:+1-804-296-0277 Fax:+1-804-296-0278
ps@fps.com (Patricia Shanahan) (07/16/90)
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