HLLs vs asm (was Re: portable "asm")

[Dave Burton]

I'm redirecting this to comp.lang.misc - it's lost all its flavor of C.
(Herman, I won't be reading comp.lang.misc, if you want, Email me - Dave)

In article <703 at l.cc.purdue.edu> cik at l.cc.purdue.edu (Herman Rubin) writes:
|Frankly, I believe that if someone developed a decent high-level, overloaded
|operator, reasonable syntax assembler it would have a good chance of
|supplanting C.  Add the other useful features of C and you have a good
|language.
 
My definition of assembler may be antiquated, but it says that there is
a one-to-one (or one to _very_ few) source statements to target statements.
I do not think such a beast as your hypothetical super-assembler is likely.
I do think C could be improved on in several areas, but which direction?
Should C's successor be system implementation oriented, or general purpose
oriented; i.e: more explicit control of the underlying machine, or more
generalized, higher level constructions? #asm is not of the latter.

|Suppose that you have a situation in a program where the implementation of
|your compiler has done something bad, like use 10 instructions and 6 memory
|references where 2 instructions and no memory references can do the job.
|The overhead of a subroutine call is likely to be more than what can be
|saved; a goto construction may not work if part of the problem is that the
|compiler will mess up register use (very common).

The number of situations where the matter of a few microseconds is a
make or break proposition is extremely limited. Where they do occur,
they are non-portable. These situations are very likely best handled
in assembly for that routine, anyway.

|Also some of the very simple hardware operations which are useful for some
|problems have not been anticipated by the language developlers.  This is so
|often the case for simple operations frequently found in hardware.  More
|machines have a hardware operation &~, which most mathematicians normally
|use \ for, than have the operation &.  I am more likely to want to use &~.

If I understand you properly, you want to switch between a HLL and assembly,
with regularity, to use machine specific instructions. I think this is in
contrast to the basic principles of high-level languages. HLLs are designed
to allow a higher level of abstraction than assembly, and somewhat more
portability.

|If a programmer says that something is inline, and this should be a feature
|of any language, the compiler should at most point out why this is not good,
|but the judgment must be that of the programmer.

Something troubles me about this statement, but I don't know what. I'm
inclined to agree.

|> [ on language gurus claiming omniscience, deleted ]
|The language gurus may not claim this, but I am not so sure.  The 
|designers of 4.xBSD clearly state in their assembler documentation
|that the assembler is _not_ for programmers, but for compiler designers
|and system maintainers.

I believe this is not so much omniscience as practicality. I *like*
programming in assembly. I like the control, the flexibility. But I
have never written a major application under Unix in pure assembly.
Why should I? I can be much more productive in C. Because it's so
inconvenient to do assembly hacking, almost nobody does it. With so
many using C, lisp, f77, ratfor, efl, what-have-you, why expend a great
deal of effort on an assembler used 99% percent of the time by automated
software?

|But in too many cases, the existing HLLs may produce good code if small
|modifications are made.  In many cases, these modifications are machine
|independent--I can give you cases of this.  It may even be as simple as
|saying
|	This is what is needed; implement this block efficiently, while
|	maintaining its compatibility with the rest of the program.
|
|That is another reason for asm.

Isn't this actually arguing against asm?

|> You presume that this same individual also knows how the HLL
|> implements itself on that machine. This is not the case. Very few people
|> that know both the HLL and the machine instruction set will know what kind
|> of code the compiler will produce.
|Why not?

OK, I know this is not quite the same, but consider interpretive languages.
Who knows what shadows lurk ... :-)
These include not only BASIC (ack!), lisp, prolog, sno[bol], but "4GL"s
like SQL, Informix, Accel and the too many others.
Even with compilers, many people do not _take the time_ to learn the
transformations performed upon their HLL by the compiler. I never bothered
to study the output of FORTRAN or Ada, but I know the assembly language
for the machines I write them on. The point is, I and most others don't
get paid to cogitate the most efficient possible expression for situation X.
(Not that I would mind! :-) It just isn't necessary to know.
-- 
--------------------"Well, it looked good when I wrote it"---------------------
 Verbal: Dave Burton                        Net: ...!ihnp4!laidbak!daveb
 V-MAIL: (312) 505-9100 x325            USSnail: 1901 N. Naper Blvd.
#include <disclaimer.h>                          Naperville, IL  60540