Xref: utzoo comp.arch:21307 comp.lang.misc:6787
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!caen!news.cs.indiana.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch,comp.lang.misc
Subject: Unusual instructions and constructions
Message-ID: <7499@mentor.cc.purdue.edu>
Date: 8 Mar 91 16:05:42 GMT
Sender: news@mentor.cc.purdue.edu
Reply-To: hrubin@pop.stat.purdue.edu (Herman Rubin)
Followup-To: comp.arch
Organization: Purdue University Statistics Department
Lines: 37

There clearly is a major disagreement on what "should" be in an architecture
or language.  One of the arguments given against including assembler code is
that compiler optimization is at least made more difficult, and portability is
lost.

What people like Montgomery, Silverman, and I, as well as many others, have
pointed out is that if the operation is not in the language, the compiler
cannot do a good job of getting the architecture to do it.  Furthermore, 
while one can always simulate what is wanted by a clumsy sequence of operations
in the language, this is at least extremely likely to generate efficient code.

Optimizing compilers "know" about certain means of translating the language
into organized combinations of hardware operations, and have some abilities
to pick efficient ones.  But they cannot include things about which they do
not have any cognizance.

The "solution" I suggest is to allow the programmer, etc., to set up idioms 
in whatever syntax is easiest to use for that programmer, and to provide the
translations into some adequate intermediate language.  There may be, and in
fact should be, alternate translations.  Even the addition of two vectors to
produce a result should have different C code on different machines.

Presumably, those types of expressions which are found useful will eventually
get into the languages.  But the expressions themselves will have considerable
portability, although if the expression is unknown in the target dialect, a
dictionary will have to be provided.

There are two reasons for posting this to comp.arch as well as comp.lang.misc.
For one, much of the discussion has been there, and it seems that many of the
posters there consider language architecture to be architecture.  For another,
by having this type of "portable" representation of what people want computed,
hardware designers may learn something about costs and tradeoffs which they are
not getting now.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)