Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!snorkelwacker.mit.edu!linus!linus!linus!mbunix!eachus
From: eachus@largo.mitre.org (Robert I. Eachus)
Newsgroups: comp.arch
Subject: Re: RISC vs. CISC -- SPECmarks
Message-ID: <EACHUS.91May8210601@largo.mitre.org>
Date: 9 May 91 02:06:01 GMT
Article-I.D.: largo.EACHUS.91May8210601
References: <3423@charon.cwi.nl> <11602@mentor.cc.purdue.edu> <820@cadlab.sublink.ORG>
	<11996@mentor.cc.purdue.edu>
Sender: news@linus.mitre.org (News Service)
Followup-To: comp.arch
Organization: The Mitre Corp., Bedford, MA.
Lines: 58
In-Reply-To: hrubin@pop.stat.purdue.edu's message of 7 May 91 13:46:25 GMT
Nntp-Posting-Host: largo.mitre.org

In article <11996@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

   The idea that there is a good language, and all the information the user
   needs to supply to the compiler is made available by machine-independent
   programming in that language, is what is debilitating.

-- No, the problem is with programmers who say: "We have always had to
-- twist the bits, and we will always need to be able to twist the
-- bits." A decade ago, we made it possible to write portable Ada code
-- which runs efficiently on many different classes of high-
-- performance architectures.  This requires that programmers be
-- willing to write X, Y, Z: Matrix(1..300,1..300);...X := Y*Z; and
-- allow the compiler (or library author) to deal with the correct
-- implementation for this architecture.  But we still get programmers
-- writing all over the place for I in 1..300 loop... which can't be
-- optimized in most cases.  (In Ada you have to be worried about
-- exception semantics. In X := Y*Z; you get the "right" answer or you
-- get an exception with X untouched...Easy to do fast on different
-- architectures, although you may have to switch pointers or do an
-- "extra" copy of the final result.  Most compilers can and do
-- recognize this case easily (and do the pointer move) if the type
-- Matrix is declared correctly.  But for the nested loops, when an
-- exception occurs, X must have the "right" junk in it. Yeech!)

   The user who understands the capabilities of the machine instructions is
   also likely to think of these things.  This includes the addition of 
   "primitive" operations to the language.  It is true that any operation
   on any computer can be emulated in any of the present languages, but not
   necessarily well.

-- I've always wanted to have a next set bit operation as a primitive.
-- Where the hardware has the necessary instructions, and given an
-- extensible language, this is not a problem.  (Although finding the
-- correct instruction is often the hardest part of the job.  On
-- Multics, and some other architectures you do this with a translate
-- and test instruction intended for fast character string operations.

   Even more than inlining is making intrinsic.  This is effectively doing
   a macro expansion of the instruction into machine primitives, with the
   full capabilities of register assignment, etc., so that full optimization
   can be carried out.

-- This is elevating a slight difference of implementation to an
-- architectural level.  Good optimizers will optimize inlined code,
-- and good languages will allow writing low level code inserts in a
-- register independent manner.  For example, the DDC-I Ada compiler
-- used to (and may still) allow code inserts in a stack-oriented
-- intermediate language which was the input to the optimizer.  These
-- when inlined were no different from intrinsics, except they could
-- be written by users.

--

					Robert I. Eachus

with STANDARD_DISCLAIMER;
use  STANDARD_DISCLAIMER;
function MESSAGE (TEXT: in CLEVER_IDEAS) return BETTER_IDEAS is...