From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Date: 28 Jul 92 13:05:18 GMT
Organization: Purdue University Statistics Department

In article <id.RKUR.GFF@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>In article <55117@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>> In article <id.YGRR.V_5@ferranti.com> peter@ferranti.com (Peter da Silva) writes:
>> >In article <54638@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:

			......................

>> If an optimization involves extensive calculation, a superfast sub-imbecile
>> can do it better than a human.

>I'm glad you noticed it. We're agreed then that these idiot savants generate
>code that is as fast as a human can write, if not the same sort of code. 

This is not always the case.  It is quite possible that a simple idea which
a human can see is not within the category of those known to the compiler.
No compiler can change the algorithm to one that it does not know about.
I can, and do.

It is like the case, almost 30 years ago, when a colleague of mine went
to get help in programming the computation of integrals with a set of
parameters.  The programmer objected to using a power series to compute
each integral, saying that numerical computation of integrals could
only be done by numerical integration procedures.  This is the difference
between the imbecilic compiler and the intelligent human.

It is also quite possible that a human can see that a relatively simple
change in hardware can eliminate a clumsy set of operations, and get a
great speedup.  

>> >> >	or	2) Most realistic code doesn't lend itself to the mode.

>> >> What is realistic code?  I will code differently if there is hardware
>> >> auto-increment for addresses.

>> >I won't.

>> Why not?  Because this would involve using an optimization not in the
>> usual set?

>Because allowing the compiler to find machine-specific optimisations is more
>cost effective than doing it myself. Because the code I write runs on Sparcs,
>68000s, 80386s, 80286s, VAXen, and 68020s. Because next month it might be
>running on MIPS or 88000. Next year it might be running on Supersparc or Alpha.
>Because optimising when you don't need to is a waste of resources.

This means that the language should be expanded to include the alternatives.
This expansion is likely to be at what could be called a basic stage, not by
adding on subroutines and functions.  

			.....................

>> >I expect any good programmer to code for the abstract machine defined for
>> >the language. Remember, software longa, hardware brevis.

>> This might be reasonable if we had a language produced by people who have
>> some respect for the capabilities of humans.

>We do. We have dozens of them.

Name one in which recognizes the various things I have previously published
in a syntax intended for fast use by a human being.  Lisp seems to have a
fairly reasonable collection of primitives, but a human being should not 
be REQUIRED to use clumsy prenex notation.  I am not convince that Lisp
has enough.  Any adequate language should have an extensible class of
operators, list (not struct) results, etc.  There MAY have been a fair
reason to leave some of these out when compilers were weak, but if the
compiler is as good as is claimed, NO.

>> An analogy to the present
>> programming languages would be a car-controller in which one could feed
>> in a destination, but would not allow manual control.

>Analogies are like instant coffee, but what you want is a little more primitive
>than that. I don't know about you, but I'm glad they don't make cars with
>manual chokes any more, or that need double-clutching when you shift.

Having had choke problems, I would prefer that cars had manual choke 
overrides, to be used when necessary.  The only problem I have ever had
with a manual choke is forgetting to turn it off.

A speaker almost missed giving a talk here because of a computer-controlled
ignition with no manual override.

I have no problem with using automation, but I object to automation 
limiting my options.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@pop.stat.purdue.edu (Internet, bitnet)  
{purdue,pur-ee}!pop.stat!hrubin(UUCP)
Newsgroups: comp.arch