From: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Reply-To: rbe@yrloc.ipsa.reuter.COM (Robert Bernecky)
Organization: Snake Island Research Inc, Toronto
Date: Thu, 30 Jul 92 05:59:16 GMT

In article <55294@mentor.cc.purdue.edu> hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
>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.

Are you suggesting that you can code better than a human?   8^}

>
>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.

Good for you. This is why Ghod created assembler code (and Bheer) and
interlanguage calls. 

There is no reason to stick with a single language merely because you
were only taught one language in school, any more than you use a hammer
for doing watch repairs: Use the tool appropriate for the job.

>
>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.

Nope, it ain't. What you are seeing is the choice of algorithms to solve
a problem, which remains a human choice, by and large.
If you gets a compiler that can do this, I think your Nobel Prize will
arrive shortly.

>
>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.  

Yes.

This is the basis, I believe, for MANY of your grumps in this group,
and although it is true, it reflects a naive view of the World of Money.

Herman's View: My problem is Really Important, and if people would only
  build hardware for it, the world would be a better place, and 
  computer people would get rich. (not sure about the last).

My View: Herman's problem is specifically hohum, because he's one of
   a small set (millions of pc's out there, Herman...) of people with this
   problem. Are computer architects going to go out and design a machine
   for Herman's Language. Not likely, unless it makes TCFP (The Corporation's
   Favorite Program run like shit through a goose.
   Why not? Because The Corporation won't be able to pay off their 
   R&D Expenses. 

What are the solutions to your problem? Here's two approaches, either
of which may reduce net bandwidth:

a. Win the lottery. Buy MicroSand, and build your machine.
b. Get a grant. This is easy for university types, who, I am told, feed
   on them. 
   Take the grant money, and get your EE dept (or the EE dept of your choice)
   to BUILD you either an ASIC (Application Specific Integrated Circuit)
   or to PROGRAM you a Gate Array to do the inner loop (hell, make it
   the N inner loops...) of your Big Problem.
   Have this chip integrated into an AT bus card, or the bus of your
   choice.

   Take one of your indentured servants (Oh, excuse me, I meant 
   graduate students), and have them write a program to interface
   your preferred language to drive said card.

   This gives you Good Performance -- I suspect that a well-designed
   system using this approach will beat the socks off of ANY systems
   designed for general use. In particular, it should scream running
   Your Favorite Application. 

The gate array approach is dirt cheap, because if you screw up, you
merely reprogram the gate array. 

I'd even consider doing this project myself, as it could be fun.
Of course, you'd have to pay through the nose, but that's what keeps
the world economy rolling, eh?

 
>>> >> >	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.  


Bad Idea Department.

Better to have a Few Good Ideas, which can be folded together effectively.
For example, J's use of an "insert" adverb, for which f/x inserts f
between subarrays of x (semantically), and evaluates the result.
Thus, 
  +/ 1 43 5
49
 NB: Summation
  =/1 0 1 1 1 
1
  NB: Parity
  >./3 4 1 99 3
99
  NB: >. is larger-of. So, >./ is maximum.

This way, you get the benefit of a language which is easy to teach 
and COMPILE, because it uses a common idea (Insert f among subarrays
of x) which has strict semantics for ANY f and x.

Your agglomerative approach makes learning and teaching a language
impossible, because it is openended.
>
>>> >I expect any good programmer to code for the abstract machine defined for
>>> >the language. Remember, software longa, hardware brevis.

Hear, hear. 

>>> 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.

Go learn APL or J.

>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

I hope that's not the papers you sent me, as I could NOT comprehend them,
and I believe myself to be a human being. By contraposition, your
intention has failed, if those were the papers...

If not, please post citations in the open literature.

>fairly reasonable collection of primitives, but a human being should not 
>be REQUIRED to use clumsy prenex notation.  I am not convince that Lisp

What clumsy notation DO you desire? Or, what other notation do you prefer?

>I have no problem with using automation, but I object to automation 
>limiting my options.

Almost any language allows you direct interlanguage calls. Go To  It.



Robert Bernecky      rbe@yrloc.ipsa.reuter.com  bernecky@itrchq.itrc.on.ca 
Snake Island Research Inc  (416) 368-6944   FAX: (416) 360-4694 
18 Fifth Street, Ward's Island
Toronto, Ontario M5J 2B9 
Canada