Path: utzoo!mnetor!uunet!husc6!mailrus!nrl-cmf!cmcl2!brl-adm!adm!MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU From: MAILER%ALASKA.BITNET@CUNYVM.CUNY.EDU Newsgroups: comp.lang.c Subject: Undelivered mail Message-ID: <12293@brl-adm.ARPA> Date: 12 Mar 88 11:07:01 GMT Sender: news@brl-adm.ARPA Lines: 112 Subject: HLLs vs asm (was Re: portable "asm") [Non-Deliverable: User does not exist or has never logged on] Reply-To: Info-C@BRL.ARPA Received: From UWAVM(MAILER) by ALASKA with Jnet id 7257 for SXJVK@ALASKA; Sat, 12 Mar 88 01:27 AST Received: by UWAVM (Mailer X1.25) id 4963; Sat, 12 Mar 88 02:20:38 PST Date: Thu, 10 Mar 88 04:13:35 GMT Reply-To: Info-C@BRL.ARPA Sender: Info-C List From: Dave Burton Subject: HLLs vs asm (was Re: portable "asm") Comments: To: info-c@brl-smoke.arpa To: Vic Kapella 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@l.cc.purdue.edu> cik@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 Naperville, IL 60540