Path: utzoo!utgpu!watserv1!watmath!att!pacbell!osc!jgk From: jgk@osc.COM (Joe Keane) Newsgroups: comp.arch Subject: Re: Why FP at all? (was: Re: Killer Micro II) Summary: The language and the machine go together. Keywords: language, machine Message-ID: <3786@osc.COM> Date: 11 Sep 90 01:42:56 GMT References: <527@llnl.LLNL.GOV> <603@array.UUCP> <2482@l.cc.purdue.edu> <1632@lhr.Morgan.COM> Reply-To: jgk@osc.COM (Joe Keane) Organization: Versant Object Technology, Menlo Park, CA Lines: 19 In article khb@chiba.Eng.Sun.COM (Keith Bierman - SPD Advanced Languages) writes: >Often folks employ the heuristic that any instruction which gets used >frequently, say 3+% of the time has certainly earned its keep. FP >instructions satisfy that. There are all sorts of other data points >also. > >Go, formalize your proposal, gather statistics from "real" programs >(spec, perfect club, US steel, etc.) using both the conventional and >your special compiler (and possibly other candiate special compilers) >on a variety of machines and publish the results and your conclusion. This doesn't work. If you get statistics from C program and make a machine based on that, you'll get a C machine. Given the way C is, this machine will be good at subroutine calls, floating-point arithmetic, and pointer dereferencing. Conversely, it will probably be not so good at co-routines, multi-precision arithemtic, and associative lookup. If you optimize the machine based on the language, and then adjust the language based on what is efficient on the machine, you're stuck in a loop. It's time to get out.