NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/arch/9239

Internet Message Format | 1992-09-07 | 8.0 KB

Xref: sparky comp.arch:9239 sci.math:11018 comp.lang.misc:2939 comp.lang.fortran:3436 comp.edu:1543
Path: sparky!uunet!pmafire!news.dell.com!swrinde!elroy.jpl.nasa.gov!decwrl!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: [e-mail] (Herman Rubin)
Newsgroups: comp.arch,sci.math,comp.lang.misc,comp.lang.fortran,comp.edu
Subject: Re: Scientists as Programmers (was Re: Small Language Wanted)
Message-ID: <[e-mail]>
Date: 4 Sep 92 22:14:25 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail] (USENET News)
Organization: Purdue University Statistics Department
Lines: 138

In article <[e-mail]> [e-mail] writes:
>In article <[e-mail]>, [e-mail]
>(Radford Neal) writes:

>|>In article <[e-mail]> [e-mail]
>|>(Herman Rubin) writes:

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

>|>>If a procedure can use some of the machine instructions and the languages
>|>>available to the programmer cause code to run considerably slower because
>|>>the languages cannot use those instructions, the languages are inadequate.
>|>>No amount of software engineering, or compiler optimization, and get around
>|>>this.  It is this feature which can make major differences in the relative
>|>>speeds of computing on different machines.

>|>This is seldom true. In fact, machines and programing languages have
>|>co-evolved in such a way as to practically ensure this.

>RISC machines are fast bercause they abolish support for assembly code. On a
>RISC machine instructions are provided for the sole benefit of compilers.

The RISC machines still have many of these useful instructions.  I do not see
how a machine can possibly be speeded up by abolishing support for assembly
code, RISC or otherwise.  A compiler which has limited capabilities will
be likely to run faster.

Many RISC machines have double register shift capabilities, condition codes
using overflow, and other such goodies.  These should be in HLLs, or easily
added to them.  The use of them is portable, even though the implementation
may not be.  The use of packing and unpacking floats is portable, and there
are definitely cases for using these operations.

There has been discussion on some of these groups about the lack of nxn -> 2n
multiplication, where n is the integer word size; this is the case on some
CISC machines, and also on some RISC machines, but others have the capability.
But I know of no HLL which allows writing this.  There is also the comparable
division operation.  The use of these features is portable.

>|>More generally, there are languages that lack certain capabilities
>|>that are available in any assembly language. Pascal does not allow a
>|>variable to contain a pointer to a procedure, for example. While some
>|>of the time this will just be an oversight, more typically, it results
>|>from a particular vision of programming, which the language is trying
>|>to support. Such visions are essential to progress, much more so than
>|>a miscellaneous collection of "features".

>This is just the generic language war taken to root. Of course no language can
>provide more capabilities than machine code. However this is irrelevant since
>working at such a low level of abstraction is too error prone to be feasible for
>anything like a large project.

None of the features I have mentioned are at "such a low level of abstraction."
These are naturally occurring operations and conditions.  There are many more
of them.  If the language does not permit these things, one has to work around
them, and these workarounds are likely to be less portable than the constructs.

The constructs of the language do need translation into machine code, and of
course this is non-portable.  But it should be possible to use these constructs
without necessarily translating them clumsily into the machinery which the
language designers decided was "adequate."  A major reason for the success
of English is that there is no attempt to keep the language "pure."


>|>>The CS curricula exascerbate the problem by indoctrinating the student in
>|>>the attitude that the machine instruction set is not to be considered in
>|>>normal programming.

>The machine instruction set is of very little relevance since it is very rarely
>the case that the target machine is known. I can predict the machines we will be
>using for the next 18 months/2 years, no more. We will certainly have at least 3
>major manufacturers involved. People who piddle about optimising their code to a
>particular machine end up stuck with it. This is OK for embedded controllers
>which we rarely change but not for general purpose stuff.

Again, there can be improvement by using machine-independent constructs,
implemented in a machine-dependent manner.

>|>Other cases would be software that has time-critical interactions with
>|>the real world, or software that runs on a machine with an unusual
>|>architecture (some parallel machines, perhaps), etc. This is why
>|>indoctrination is bad - you need to known when an exception comes up.

>We run massively parrallel machines and have a massive data rate to cope with.
>Thats why we *have* to use high level languages, the complexity of the problem
>is too great to allow use of machine code.

Wrong again!  Massively parallel machines require, for efficiency, the
elimination of branches as much as possible.  This calls for really CISC
architecture, and quite a few tricks not envisioned by the HLL designers.
A switch operator is likely to end up taking every branch, so every
processor spends the time for every branch.  It is more important that
massively parallel machines find a way to reduce this than to avoid
machine instructions, especially if the machine instructions can eliminate
branches, as is often the case.

>|>>There can, and should, be interaction at compile time between the compiler
>|>>and the programmer.  The compiler also should be able to suggest rearranging
>|>>machine instructions, not just the output from HLLs.

>|>This would occasionally be useful. I sometimes look at the output of
>|>the compiler to see if it is generating reasonable code, and to find
>|>out if there's any point in my doing certain optimizations at the
>|>source level (e.g. loop unrolling). This is reasonable for me to do
>|>because I have years of experience at this sort of thing. It probably
>|>isn't reasonable for you to do it.

>If we needed that type of optimisation we would either buy a compiler which did
>it or write our own.

Not all of us have this option.  Those of us who are in American universities
rarely have either choice.  Also, I doubt if one could buy such a compiler at
this time.

>|>>What we are teaching the CS students, and even the software engineers, is
>|>>essentially the mistake made in teaching methods without understanding in
>|>>mathematics and statistics.  Someone who has only learned a particular
>|>>collection of methods is extremely unlikely to consider anything not in
>|>>that particular bag of tricks.  Training is not education.

>|>Yes. A CS graduate who intends to work as a software engineer should
>|>BE ABLE to work at all levels, even more so for a computer scientist
>|>designing a new programming language or operating system. They should
>|>also know enough not to work at the machine level unless there is a
>|>good reason, which isn't very often for application programming. Most
>|>non-professional programmers would be well advised to think about
>|>their problem more, rather than learn the assembly language of the
>|>machine they are using this month.

>We shiould stop calling it Computer Science and call it engineering.

>Machine code is important, CS graduates should know how to build compilers and
>processors.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: [phone]
[e-mail] (Internet, bitnet)
{purdue,pur-ee}!pop.stat!hrubin(UUCP)