colwell@uunet.UUCP (Robert Colwell) (02/12/88)
=In article <231@m2.mfci.UUCP>, root@mfci.UUCP (SuperUser) writes: == In article <3536@batcomputer.tn.cornell.edu> kahn@tcgould.tn.cornell.edu (Shahin Kahn) writes: == =VLIW has been part of Floating Point Systems' machines for more than == =10 years. == == Under that definition of VLIW, every microcoded machine ever made == qualifies. It's never been that big a trick to make a machine with == many parallel functional units. The trick is to be able to keep them == busy without hand coding, and to provide the right interface so that == the compiler can express the parallelism that it finds. == == Read Ellis' thesis; he presents reasonable arguments as to why FPS' == architectures have hot spots that make it a very difficult target == for a compiler. == =1) Contrary to popular impression, FPS has been compiling directly from =FORTRAN to their 64-bit "LIW" 164 machine since the early '80s. =...... =In fact, I believe Josh Fisher & Co. used 164 hardware for their early work at =Yale that grew into Multiflow. = =I suppose it's just a consequence of FPS' non-existent paper publishing and =lack of marketing that people generally still think FPS machines are hand-coded =array processors. There is no code between the FORTRAN and the 64-bit LIW, =and the LIW fields are encoded and at a minicomputer level of expression, =thus it is not microcode. =... =Don't get me wrong, I have a high opinion of the way Multiflow is developing =VLIW technology, I just feel the early FPS people (I wasn't one of them) should =get more credit for blazing this trail 5-10 years ago. =... =-- =Mike Butts, Research Engineer KC7IT 503-626-1302 =Mentor Graphics Corp., 8500 SW Creekside Place, Beaverton OR 97005 =...!{sequent,tessi,apollo}!mntgfx!mbutts OR mbutts@pdx.MENTOR.COM My only interest here is the same as Mike's: I want the historical record to be correct. Consequently, I have to repeat, the only effect that the FPS machines ever had on the VLIW research of Josh Fisher was a negative one -- Josh realized early that there had to be some better way to make use of parallel functional units than what FPS was providing. They did not use any FPS hardware at any time. (The Yale CS dept. had an FPS-164; maybe that's what you're thinking of). And I know very well that FPS machines are not strictly hand-coded anymore. But perhaps it's a measure of how hard it is to compile to that style of machine that, in spite of their higher peak megaflops and the fact that they've been in business for many years, they seem to be having a great deal of trouble competing these days. Do they have their compiler act together to the point where they can compile UNIX and run it on the native machine? I know it sounds like we're (meaning Multiflow) trying to avoid giving any credit to anybody else for the origins of VLIW work, but facts is facts. There are some legitimate influences that Josh cites for inspirations. But the VLIW architecture derived from thinking about what the ideal target for a trace scheduling compiler would be, not the other way around, and FPS was not one of the influences. Bob Colwell Multiflow Computer <Above is personal opinion only!!> 175 N. Main St. Branford CT 06405 mfci!colwell@uunet.uucp 203-488-6090