daveb@laidbak.UUCP (Dave Burton) (03/10/88)
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 <disclaimer.h> Naperville, IL 60540
blarson@skat.usc.edu (Bob Larson) (03/25/88)
In article <1600@ogcvax.UUCP> pase@ogcvax.UUCP (Douglas M. Pase) writes: >``C'' allows you to >ignore types when you really want to, The only way it allows you do do this is via unions, equivelent to pascal's varient records. Casts are (by definition) conversions, while some seem silly and produce no code on many machines, they still never allow you to "ignore types". Pointers DO NOT violate this, while it is possible to cast any pointer to a void or char pointer and back, it is not required that the char pointer be meaningful. (Ever heard of "split I & D"? How about extending this so char and int storage are seperate?) > plus it allows access to the "bare >metal", etc.) Are we talking about the same language? -- Bob Larson Arpa: Blarson@Ecla.Usc.Edu blarson@skat.usc.edu Uucp: {sdcrdcf,cit-vax}!oberon!skat!blarson Prime mailing list: info-prime-request%fns1@ecla.usc.edu oberon!fns1!info-prime-request