Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!husc6!sri-unix!rutgers!sunybcs!boulder!hao!oddjob!gargoyle!ihnp4!occrsh!erc3ba!sd From: sd@erc3ba.UUCP (S.Davidson) Newsgroups: comp.arch Subject: Re: D-machine helped spawn RISC Message-ID: <349@erc3ba.UUCP> Date: Fri, 18-Sep-87 08:40:05 EDT Article-I.D.: erc3ba.349 Posted: Fri Sep 18 08:40:05 1987 Date-Received: Sun, 20-Sep-87 11:16:42 EDT References: <347@erc3ba.UUCP> <478@esunix.UUCP> Organization: AT&T ERC, Princeton NJ Lines: 90 Summary: WIC Computers (was WISC, VLIW) > > A good reference is "Trace Scheduling: A Technique for Global Microcode > Compatction" Joseph A. Fisher. IEEE Transactions on Computers, vol. c-30, > no. 7, July 1981. Right after our paper on microcode compaction techniques, in which we had the pleasure of killing off a research area, by showing that the problem was solved. We didn't really invent any of the compaction techniques in that paper, by the way, but implemented and compared the popular ones. The reference is "Some Experiments in Local Microcode Compaction for Horizontal Machines," by S. Davidson, D. Landskov, B. D. Shriver, and P. W. Mallett., reprinted in "Advances in Microprogramming" ed. by Mallach and Sondak, Artech House, 1983, (second ed.) A better article (but without the results) is "Local Microcode Compaction Techniques," Computing Surveys, Sept. 1980, with David Landskov as first author. Unfortunately I haven't seen any complete solutions for the global compaction problem. Josh's ideas are still the best, I think, but the jury is still out. > > By the by, VLIW(TM) and Trace Scheduling(TM) are trademarks of Multiflow > Computers, Inc. So I chose to use WISC instead. > I wonder if Trace Scheduling as a trademark would stand up in court. It was used as a description of a particular algorithm in several papers before this company existed. Wide Instruction _Set_ Computer doesn't seem right, a reduced instruction set makes sense (the set is reduced, not the instructions) but what is a wide instruction set. How about wide instruction computer? I'm not sure that makes any more sense, though. VLIW seems the best description, too bad they grabbed the term. > - microcode. Josh moved to Yale after he graduated, and then moved to a > - company to build a VLIW machine. I don't know the current status of this machine, > - though. At Yale, though, Josh got some very impressive speedups from unrolling > - loops and basically running compaction on them, assuming a lot of available resources. > - I don't know of any results on real hardware, however. > > A good reference is "Bulldog: A Compiler for VLIW Architectures" John R. Ellis > MIT Press, 1986 ISBN 262-05034-X > The reference to their simulated results is "Using an Oracle to Measure Potential Parallelism in Single Instruction Stream Programs," by Alex Nicolau and Josh, 14th Annual Microprogramming Conference, pp. 171 - 182. Alex was Josh's student, he is now a professor at Cornell, (or was 2 years ago when he wrote a paper form Micro 18). > - > - By the way, I wouldn't say that RISCs are vertical microcode engines done right. > - They just include a lot of stuff not necessary in microcode, like direct > - addressing and multiplies. It has never been that hard to generate compilers > - for vertical microcode. > > The world YOU live in doesn't need direct addressing and multiplies in > microcode. The world I live in requires direct addressing and multiplies, > even floating multiplies, in microcode. Out side of your own world, your > assumptions do not apply. You might be interested in reading "The Cultures of Microprogramming" by Nick Tredennick, Micro 15, pp. 79 - 83. Sheraga and Gieser have done some very nice work on compilers for microcode with floating point and all that stuff, (one paper is in Micro14, others have been in IEEE Trans. Comput. or Software Eng, I forget which. The issue really is however, how are RISC machines done "right" in comparison to vertical microcode engines, considering the difference between a microcode engine and a computer. > > It has been very hard to write GOOD compilers for horizontal microcode. > I think I know that, having written one (a compiler, not necessarily a good one.) It is very hard to write even bad compilers for horizontal microcode. Your audience for the compiler makes a big difference too. See my article "Progress in High Level Microprogramming," in the July 1986 IEEE Software. Not enough references there, Bruce made me take most of them out. There is a more extended article on high level microprogramming languages in the book "Microprogramming Handbook," ed. by Stan Habib, out Real Soon Now. > Please read what I said, not what you wanted me to say. The original article > contained references to two key papers in this field. Using anecdotes and > rumors to "correct" me is as pointless as my flaming you in this reply. At > least I've provided references to cover your anecdotes. > Never meant to correct you, since there was nothing to correct. I'm not sure all the readers of this group are up on WICs or whatever. By the way, what is a reference for a 15 year old WIC? I mean one like the Multiflow, Bulldog machine, not a big heterogeneous horizontal word. > Bob P. > -- > Bob Pendleton @ Evans & Sutherland > UUCP Address: {decvax,ucbvax,ihnp4,allegra}!decwrl!esunix!bpendlet > Alternate: {ihnp4,seismo}!utah-cs!utah-gr!uplherc!esunix!bpendlet > I am solely responsible for what I say. Scott Davidson {ihnp4,allegra}!erc3ba!sd