brewer@umd5.umd.edu (Peter Brewer) (06/28/90)
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..
ps@fps.com (Patricia Shanahan) (06/29/90)
> 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