Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!csinc!rpeglar
From: rpeglar@csinc.UUCP (Rob Peglar)
Newsgroups: comp.arch
Subject: Re: HW support for primitives (was Re:Graphics Primitives)
Summary: Portability is key.
Message-ID: <241@csinc.UUCP>
Date: 10 Nov 90 21:47:56 GMT
References: <0093F6A8.35049DA0@KING.ENG.UMD.EDU> <11030@pt.cs.cmu.edu> <42992@mips.mips.COM>
Organization: Control Systems, Inc., St. Paul MN
Lines: 51

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