Path: utzoo!attcan!uunet!husc6!think!ames!zodiac!joyce!sri-unix!quintus!ok
From: ok@quintus.uucp (Richard A. O'Keefe)
Newsgroups: comp.lang.misc
Subject: Re: Many people's opinions on computer languages
Message-ID: <382@quintus.UUCP>
Date: 12 Sep 88 06:57:17 GMT
References: <3938@enea.se> <923@l.cc.purdue.edu>
Sender: news@quintus.UUCP
Reply-To: ok@quintus.UUCP (Richard A. O'Keefe)
Organization: Quintus Computer Systems, Inc.
Lines: 46

In article <923@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
>I use many operations which the languages do not know about.  Now I can
>translate them into hardware instructions.  I can even post to comp.arch
>that additional instructions would be useful.  But if I have to write
>twenty lines of code to even get them clumsily expressed in a HLL, the 
>human time which Erland Sommerskog decries is equally wasted.  Especially
>if I have many such situations.  In addition, the clumsy encoding in C
>or FORTRAN might not be understandable to others.
>
>Programming time is therefore not necessarily faster in HLLs.  Frequently,
>I see how to use a machine instruction or instructions to accomplish something
>which I consider simple and obvious.  Why should I even have to try to find a
>way to do in in some HLL?  The HLL gurus have left out too much.

Please tell us about some of these instructions.

In an earlier posting, I reported that I had studied the MC680x0
instruction set and found very few instructions which a PL/I compiler
could not make good use of.  [Whether there is a PL/I compiler which
does so is another matter.]  Admittedly, the MC680x0 architecture does
not include floating point operations.  They are handled by the
MC688[12].  I have not done a similar study for that, but I consider it
plausible that a PL/I compiler could exploit most of them, even to
providing access to 80-bit "extended" floats.  PL/I even has the
preprocessor facilities which are required to exploit hardware features
in a quasi-portable manner.

[I do not mention PL/I because I think it is a particularly good language,
but because Rubin singled it out for special attack.]

This is not the case in C.  However, some C compilers (such as the SunOS
ones) have an "inline" facility which can be used by an ordinary programmer
to write function calls in his source code and have them expanded into the
assembly code of his choice (before the final peephole optimisation pass).
Some months ago I posted an example in comp.lang.c showing how 
	find Q=X div D, R=X mod D where X = A*B+C
could be done this way, X being 64 bits and the other variables 32 bits.
Recent System V C compilers have "asm procedures" which can be used the
same way.  Thus there is no instruction on an MC680x0 or Intel 80386
which cannot be generated by a UNIX C compiler, with *no* function call
overhead.

ADA provides a standard form (package MACHINE_CODE, in LRM 13.8) for
"machine code inserts" by means of which any instruction can be requested
by the programmer (though this package is optional).  Perhaps ADA would
suit Rubin's needs?