🚀 go-pugleaf

> I was reading in EE times about the FPS system with multiple sparc processors,
> vector processing units, and 860 chips to do 'forever jobs'. Gee I wonder
> what a compiler would like like for this thing?? I know on machines which
> are hybrids like the CM-2 you end up playing games with adding facilities to
> 'load' the different instructions at the appropriate times in the generated
> code.. but the CM-2 is 'synchronous'.. what happens with an asynchronous 
> beast like that?
> 
> -- Peter Brewer
>    brewer@umd5.umd.edu..
> 
> 

The problem is actually a lot simpler than it sounds because it can
be divided into two parts: compilation for a SPARC scalar and
optional vector system, and compilation for a matrix co-processor
built from multiple i-860 processors.

The first part differs from compilation for existing Model 500
systems only in the choice of SPARC as the scalar instruction set
instead of a non-standard instruction set. FPS will supply
compilers, as we do for the existing Model 500 systems.
Alternatively, for pure scalar code, programers will be able to use the
SPARC compiler of their choice. Except for the existence of other
suppliers of compilers for the scalar instruction set, this is the
normal vectorizing compilation situation.

The matrix co-processor will do whole functions, rather than individual
vector operations. Its code will be generated by a FPS-supplied i-860 
compiler. The FPS Model 500 program will contain calls to invoke a 
function on the matrix co-processor. The scalar processors view the
matrix co-processor as a single entity that just happens to do
matrix functions fast.

Consider a SPARC program that uses some FPS math library calls.
There will be three implementations of those library calls that
could be used. The first one just uses the Fortran source compiled
for SPARC. That version will run on any SPARC that has the memory
and floating point performance for the problem being solved. The
second version would contain vector code that, for the more critical
functions, will be hand optimized. That version would use a vector
processor. The fastest (for reasonably big problems) version would
just contain a stub routine that passes the problem off to the
matrix co-processor.

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