Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!psuvax1!gatech!purdue!mentor.cc.purdue.edu!l.cc.purdue.edu!cik
From: cik@l.cc.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: VLIW Architecture
Summary: Hardware instructions not in HLLs affect performance greatly.
Keywords: vliw
Message-ID: <1629@l.cc.purdue.edu>
Date: 3 Oct 89 12:41:20 GMT
References: <251FCB3F.12366@maccs.dcss.mcmaster.ca> <1050@m3.mfci.UUCP> <13038@pur-ee.UUCP>
Organization: Purdue University Statistics Department
Lines: 64

In article <13038@pur-ee.UUCP>, hankd@pur-ee.UUCP (Hank Dietz) writes:
> In article <1626@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

> >As one who always finds ways to use the architecture that the compiler
> >writers did not think about, I maintain that this book helps little.
> 
> VLIW machine compilers essentially search for optimal schedules of
> instructions; I don't see how a full-width search could be ommitting things
> that Dr. Rubin would want to do.  ;-)
> 
> >Why is it the case that people in the computing field think that someone
> >can understand a computer in ignorance of its instruction set and the
> >temporal operation of those instructions?

What kind of integer arithmetic is there in hardware?  Examples of the
problem are what kinds of integer products can be formed in one operation.
Some machines can form long x long -> double long in one operation, and
some cannot.  Some allow this to be done unsigned and some do not.  Some
machines allow double/single getting quotient and remainder in one operation
and some do not.  Some allow this to be unsigned and some do not.

Some machines have hardware square root and some do not.  A few allow 
fixed-point arithmetic, but most do not.  Different machines have different
addressing modes; vector operations should be coded differently depending on
that.  I have profitably used bit operations on floating-point numbers; this
means that I must know the exact representation.

How do you code the following:  look at one bit and transfer if it is a 1,
setting pointers so that that bit will not be looked at again?  In the cases
where I envision using this, it is a tool and will be used frequently.  
Another such is the spacing between 1's in a bit stream, and in this case 
there are alternatives.

What does your HLL have to say about these?

> The primary reason humans have done so well is not that we are so much
> better than other life forms, but rather that we build much better tools.
> To accomplish any large task, a human must be able to be ignorant of at least
> some details -- VLIW compiler technology is a prime example of a mechanism
> keeping track of, and optimizing use of, a structure too complex for humans
> to manage directly.

The human knows when not to use the tools provided.  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.  The compiler maps a
route on Interstates; I find a short cut on good roads.  Will an autodriver
let you back the car out of the garage so you can clean the garage?

> I suppose you'd rather not use any tools...  but then why do you want to use
> the tools called "computers?"

Use the best tool for the user and the job.  The crude mechanic must put the
car on the analyzer and use what it tells him.  There are a few good mechanics
who can do better listening to the engine.
	
> 						-hankd@ecn.purdue.edu
> 
> PS: Dr. Rubin's views do not represent those of Purdue University.  ;-)

PPS:  Neither do those of Dr. Dietz.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet, UUCP)