Path: utzoo!attcan!uunet!jarthur!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!oscsunb!djh From: djh@osc.edu (David Heisterberg) Newsgroups: comp.arch Subject: Re: New instructions for RISCs (was Re: Byte ordering) Keywords: bitblt Message-ID: <140@illini.osc.edu> Date: 12 Feb 90 14:08:15 GMT References: <7345@pdn.paradyne.com> <168@zds-ux.UUCP> <79N15F5xds13@ficc.uu.net> Organization: Ohio Supercomputer Center, Columbus, OH, USA Lines: 21 In article , peter@ficc.uu.net (Peter da Silva) writes > > The most common compute-intensive use of scalar merge (your terminology) in > workstations seems to be in display management: the BitBlt operator in one of > it's many guises. And BitBlt would benefit from bit-aligned LOAD, an operation > that's no more expensive in real-estate than byte-aligned LOAD... a barrel- > shifter is a barrel-shifter is a rose. "scalar merge" is CRI's terminology, not mine, and, unfortunately, one can't quite consider a CRAY to be a workstation. In the case of BitBlt, though, you're probably right. However, that's not what I (or the cft77 compiler) use it for, but then there's more of you than there are of me. In my experience, the main use of scalar merge is in generating masks for vectorization code. This is somewhat specialized, I must admit, but unless your scalar support code is very fast, it, rather than vector operations, will dominate the run time. David J. Heisterberg djh@osc.edu The Ohio Supercomputer Center djh@ohstpy.bitnet Columbus, Ohio ohstpy::djh