🚀 go-pugleaf

In article <596@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>In article <3603@sol.ARPA>, crowl@cs.rochester.edu (Lawrence Crowl) writes:
>> In article <594@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:

><< I suggest that the software developers first consider the power of existing
><< hardware, next the natural power of hardware (what unrealized operations can
><< be easily done in hardware but are not now there), and finally the "current
><< use."
>> 
>> No, software developers should first consider the task to be solved.  The 
>> efficient use of the hardware is moot if the software does not meet the need.
>
>Which of the tasks to be solved should the software developer consider?  On one
>machine there may be hundreds or even tens of thousands of users.  Some of
>these users may have dozens of different types of problems.  

Then the software developer has dozens of tens of thousands of tasks to solve!
There aren't enough software people in the world to solve each problem in an
individual and idiosyncratic fashion, so instead several tasks are decreed to
be "similar", which really means that some compromises have to be made.
This situation is not unique to software.  For example, bridge designers don't
usually get new and unique rivets for each bridge - instead, they have to order
from a catalog.

Everybody wants every one of their programs to be maximally efficient on all
imaginable hardware, while at the same time spitting on programmers because
it doesn't happen at the press of a couple keys.  It's unfortunate that the
popular culture encourages the belief that hackers can conjure up complicated
programs in a few seconds.  I suspect it even influences people who should
know better.  To quote Fred Brooks, "there is no silver bullet".

>And should we use the same algorithm on different machines?
>I, for one, would question the intelligence
>of those who would attempt to enforce such restrictions.

I find it interesting that the people who have been programming the longest -
numerical analysts - are exactly those who use dozens of different algorithms
to solve the same problem, each with slightly different characteristics.
Could mean either that multiplicity of algorithms is coming to the rest of
computing soon, or that numerical analysts haven't yet found the correct forms
for their algorithms...

>> User modifiable syntax is a very difficult to define consistently and very
>> difficult to parse.  The consensus so far appears to be that it is not worth
>> the cost.
>> 
>If the syntax is somewhat limited, it will still be very powerful and not so
>difficult to parse.  The reason that the typical assembler language is so 
>difficult to use is due to the parsing difficulty 35 years ago.  Except for
>not using types, Cray's assembler constructs on the CDC6x00 and on the CRAY's
>go far in the right direction.

I think you would have a hard time proving that the minor syntactic 
improvements of the Cray assembly language (with which I am familiar)
have any effect at all on productivity, reliability, etc.  After all, Lisp
programmers can be immensely productive even though the assignment statement
has a verbose prefix (!) syntax.

>Who is the target audience?  There is no adequate language for the production
>of library subroutines.

Aha!  I wondered if that was the motivation for the original posting...
You have touched upon my thesis topic; but you will not have to die for it :-).
My thesis is most directly concerned with the implementation of Lisp runtime
systems, which have many similarities to Fortran libraries (really).
The basic angle is to supply formal definitions of the desired functionality
and the hardware, then to use an rule-based system to invent and analyze
designs.  Not very intelligent as of yet, but I have hopes...

Of course, this approach involves a couple assumptions:

1. As you say, there is no "adequate" language for the production of library
subroutines.  After poking through the literature, it is pretty clear to me
that no one has *ever* designed a high-level language that also allows direct
access to different kinds of hardware.  There are reasons to believe that such
a beast is logically impossible.  The output of my system is machine-specific
assembly language.

2. I also assume that human coding expertise can be embodied in machines.
What compilers can do today would have amazed assembly language programmers
of 30 years ago.  There is no reason to believe that progress in this area
will encounter some fundamental limitation.  I've seen some recent papers (on
the implementation of abstract data types using rewrite rules) that still seem
like magic to me, so certainly more advances are coming along.  Closer to
reality are some compiler projects that attempt to figure out optimal code
generation using a description of the target machine.  This is extremely
hard, since machine "quirks" are usually more like machine "brain damage".

>The user should be able to introduce type definitions (structures in C), new
>operators (such as the very important &~, which may or may not compile
>correctly), and overload old operators.  This should be very flexible.

Take a look at HAL/S, which is a "high-level assembly language" used in the
space shuttle computers.  Allows very tight control over how the machine
code will come out.  In fact, there are probably a few people reading this
group who could offer a few choice comments on it...

><<         3.  Designed with the idea that anything the user wants to do should
><< be efficiently representable in the extended language.
>> 
>> What do you mean?  Is the resulting representation efficient with respect to
>> execution time?  Is the resulting representation efficient with respect to
>> run-time storage requirements?  Is the representation of what the user wants
>> concisely represented in the source?  Choosing one of these options might lead
>> one to design C, Forth or Prolog, respectively.
>> 
>First execution time, second storage.  I do not advocate obfuscated code to 
>attain this, and I do not believe it is necessary.  None of the languages you
>have cited meet any of my points.

What's wrong with Forth?  It can be extended in any way you like, it can be
adapted to specific machine architectures, the syntax is better than raw
assembly language, and its compilers don't do awful things behind the user's
back.  You'll have to be more specific on how it fails.  I agree with you that
C and Prolog cannot always be adapted to machine peculiarities.

>The VAX has twelve general-purpose registers available.  If I write a program
>which uses eleven registers, I object to the compiler, which does not need any
>registers for other purposes, only giving me six.

How do you know it "does not need any registers for other purposes"?  Are you
familiar with the compiler's code generators and optimizers?  Writers of code
generators/optimizers tend to be much more knowledgeable about machine
characteristics than any user, if for no other reason than that they get the
accurate hardware performance data that the customers never see...

>An obvious example of this is [...] the denial of such
>simple elegant ideas as goto.

"Goto" is neither simple nor elegant on parallel machines.

>The bit-efficient algorithm above starts out
>with a case structure; I immediately observed that, by 99.999% of the time
>keeping the case as a location only and using goto's, the code would be
>considerably speeded up without any loss of clarity.

OK, this is the time to use assembly language.  What's the problem with that?
It's the accepted technique; no one will fault you for it.

>> Efficient code almost always takes longer to produce than inefficient code.
>> You must invenst development time to get efficiency.
>> 
>This is because of the badness of the languages.  I do not mean completely
>efficient code is easy to produce, but I thik that 80% to 90% will not be
>that hard to get.

(I assume 80-90% of optimal is meant)
You had better come up with some hard evidence for that.  Various computer
scientists have been trying to prove for years that the right language, or 
the right method, or the right environment, or the right mathematics will
make efficient programming "easy".  So far no one has succeeded, but the
journals are full of polemic and anecdotes masquerading as scholarly work.
It's really depressing sometimes.

No silver bullet...

><< Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907
>>   Lawrence Crowl		716-275-9499	University of Rochester
>Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907

							stan shebs
							shebs@cs.utah.edu