From: peter@ferranti.com (Peter da Silva)
Subject: Re: CISC Microcode (was Re: RISC Mainframe)
Organization: Xenix Support, FICC
Date: Wed, 29 Jul 1992 13:50:04 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:
> >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.

Yes, I quite agree, different problem spaces demand different algorithms for
solution. However, and this is the key point, it is (in 1992) extremely rare
that you encounter a constraint on the problem space due to the hardware that
has any significant effect on the choice of algorithm. Things like 64K segment
limits, massively parallel hardware, or the absence of a FPU... yes. Things
like the presence or absence of autoincrement addressing... no. It's been many
years that microoptimisation for the instruction set has been cost-effective
outside of tight loops.

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

Why? So I can write the same code half a dozen times? Whether I do so by
coding a loop in five different assembly dialects or by coding a bunch of
alternatives in Herman Rubin's Perfect Language it's still a waste of time.

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

The various things you're looking for are in the "tight loop" category, and
the effort of coding them in assembler is negligable compared to the cost of
coding the rest of the program in a language designed for microoptimisation
rather than expression of an algorithm.

C++ with embedded assembly and inline expansion.
Forth.
C with inline assembler.
Turbo Pascal.
Dec Fortran 77.
Most modern Lisp dialects.

> Lisp seems to have a
> fairly reasonable collection of primitives, but a human being should not 
> be REQUIRED to use clumsy prenex notation.

Oddly, many human beings prefer it. HP has managed to remain the last
successful US calculator manufacturer by using a similar notation.

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

Why am I not surprised?
-- 
Peter da Silva                                               `-_-'
$ EDIT/TECO LOVE                                              'U` 
%TECO-W-OLDJOKE Not war?                        Have you hugged your wolf today?
Ferranti Intl. Ctls. Corp.      Sugar Land, TX  77487-5012       +1 713 274 5180
Newsgroups: comp.arch