Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!mentor.cc.purdue.edu!pur-ee!hankd From: hankd@pur-ee.UUCP (Hank Dietz) Newsgroups: comp.arch Subject: Re: VLIW Architecture Summary: Read about VLIW -- it is good stuff. Keywords: VLIW Message-ID: <13050@pur-ee.UUCP> Date: 3 Oct 89 23:06:57 GMT References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP> <13038@pur-ee.UUCP> <1629@l.cc.purdue.edu> Reply-To: hankd@pur-ee.UUCP (Hank Dietz) Organization: Purdue University Engineering Computer Network Lines: 30 In article <1629@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: ...[numerous "why don't HLLs let me say..." flames omitted]... >What does your HLL have to say about these? What HLL? What does this have to do with VLIW techniques? Dr. Rubin is complaining about languages -- but we are talking about VLIW compiler analysis and program transformation technology, not language design. I hope that this confusion is not common. Perhaps a lot of compilers do blindly spit-out the "obvious" code for badly-designed language constructs, but that certainly isn't the state of the art. I would think that a person who has spent some time counting T-states would really appreciate the VLIW work that Ellis presents in his award-winning PhD thesis... I know I do. >... Are you so dead sure that >I cannot manage such structures better than the compiler? The most complicated >instruction set I have seen is MUCH simpler than HLLs. ... VLIW technology is complex because of its use of parallelism -- it has very little to do with instruction set complexity issues. Generating good code for a VLIW is most like microcode scheduling/compaction for a huge, asymmetric, microcoded machine. You really don't even want to try it by hand... well, I know I don't. And why bother? VLIW compiler techniques come very close to optimal schedules every time. I can't match it, let alone beat it. -hankd@ecn.purdue.edu "A good workman is known by his tools." Intro to Chapter 12, F. Brooks, "The Mythical Man-Month," p. 127.