rpeglar@csinc.UUCP (Rob Peglar) (11/11/90)
In article <42992@mips.mips.COM>, mash@mips.COM (John Mashey) writes: > > I would claim that most of the most successful products are > those that understood carefully > the nature of the necessary primitives that could accelerate software > in ways difficult for software to duplicate, without getting too > specific that it couldn't adapt to later changes in expected software. > Maybe people have examples or counter-examples. The world of supercomputing gives perfect examples. In the ETA-10 and predecessor line of processors, there were many very specific instructions that used the vector and/or string units for primitive arithmetics like "delta" (difference operator) or operators such as square root. There was even a polynomial evaluation instruction - yep, eval a polynomial in hardware. (not on all machines in the series, mind you). In software, FORTRAN specifically, the access to these instructions was either write-it-yourself using callable assembler modules, or using a rather arcane embedded assembler syntax known as "q8". (I omit gruesome detail) Neither won favor. Callable assembler suffered overhead penalty of call/return, not an insignificant thing in this architecture. Q8 stuff was one of the most non-portable syntaxes I have ever encountered. As for C it was actually slightly easier - one could embed real 'as' inside modules for the compiler to swallow. Primitives of this sort were just wonderful once the application was executable. Getting there was a real pain in many cases, pain enough to make some people switch architectures (ironically, back to the 6600-type from which many of these same people came, manifested in the CRI machines) or drop "down" to WS-type architectures, just for ease of development. So, moral is arch. support for primitives is good, but the primitives have to be able to be invoked from the language in which one develops. New operators must be embedded into a language; made as easy as +=, for instance. Then, and only then, will arch. support for primitives be a big win. Here's hoping that the ANSI X3[various] committee people see the win for (something akin to) drawline(x1,y1,x2,y2) as just another operator. Rob > -- > -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> > UUCP: mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash > DDD: 408-524-7015, 524-8253 or (main number) 408-720-1700 > USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086 -- Rob Peglar Comtrol Corp. 2675 Patton Rd., St. Paul MN 55113 A Control Systems Company (800) 926-6876 ...uunet!csinc!rpeglar
cik@l.cc.purdue.edu (Herman Rubin) (11/12/90)
In article <241@csinc.UUCP>, rpeglar@csinc.UUCP (Rob Peglar) writes: > In article <42992@mips.mips.COM>, mash@mips.COM (John Mashey) writes: ........................... > The world of supercomputing gives perfect examples. In the ETA-10 and > predecessor line of processors, there were many very specific instructions > that used the vector and/or string units for primitive arithmetics like > "delta" (difference operator) or operators such as square root. There > was even a polynomial evaluation instruction - yep, eval a polynomial in > hardware. (not on all machines in the series, mind you). > > In software, FORTRAN specifically, the access to these instructions was > either write-it-yourself using callable assembler modules, or using a > rather arcane embedded assembler syntax known as "q8". (I omit gruesome > detail) Neither won favor. Callable assembler suffered overhead penalty > of call/return, not an insignificant thing in this architecture. Q8 stuff > was one of the most non-portable syntaxes I have ever encountered. As for > C it was actually slightly easier - one could embed real 'as' inside > modules for the compiler to swallow. Having used the call q8 pseudo-Fortran-calls to insert machine instructions, fI am quite aware of the problems involved with them. But it is not much worse than the inserted assembler instructions which C allows. Both of these suffer from the fact that the user cannot set up a sensible notation for the operation; it is my opinion that in the past 20 years, few assembler designers have even considered that they may be USED by other than compiler writers. The MACHINE instructions are not hard to use. But the wholly artificial and inconvenient assembler and call q8 syntax is. There is an alternative; a translator. This is merely a weak front-end part of a compiler. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!hrubin(UUCP)