tjr@ihnet.ATT.COM (Tom Roberts) (03/09/88)
Dave Burton writes: >> [omitted discussion of #asm ... ] >>Do *not* mix languages in a single source file. There ARE times when mixing ASM within a C source file is VERY USEFUL. The 8086-class of processors, with their segmented architectures, requires a C compiler to support several different memory models having different-length pointers. In many development environments it is difficult to communicate the current memory-model of the C compiler to the assembler (so ASM code can use IFDEF-s based on memory model). Thus, it is better to have a C compiler that allows inline ASM code; for ASM routines you simply declare a C function which contains only (mostly) ASM code; a good compiler will handle arguments and globals appropriately. E.g. Turbo C: void asm_sum(unsigned long *sum, unsigned int arg1, unsigned int arg2) { asm mov ax,arg1 asm mul arg2 asm mov arg1,ax /* lsb */ asm mov arg2,dx /* msb */ *sum += arg1 + (arg2<<16); } This program will compile correctly in all memory models (note the careful mixing of C and ASM - performing the last statement in ASM requires ASM IFDEF-s on memory model). [program written from memory - actual syntax may vary slightly - I forgot whether Turbo C can handle a union in ASM code, so I used that ugly shift - this is an EXAMPLE, not a real program] Sometimes it is desirable to avoid the function call overhead for this kind of function - inline ASM allows you to directly use the full resources of the processor, not just those that the C compiler happens to use. Clearly, portability suffers, but some of us need PERFORMANCE, not portability (e.g. the program is inherently written for a given graphics board). Tom Roberts AT&T Bell Laboratories ihnp4!ihnet!tjr
quiroz@cs.rochester.edu (Cesar Quiroz) (03/09/88)
Herman Rubin has consistently criticized in this group high-level language designers/implementors for not producing the portable assembler he wishes to use. (Quotes here are from article <703@l.cc.purdue.edu>, but if you have been reading this group you could supply abundant examples of your own.) For instance, :... :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. :... :I consider a programming language and an operating system to be a procedure :whereby the user is enabled to more easily use the power of the computer. :It is a great mistake to restrict a programming language. :... :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. Nice, pro-freedom stance. It is easy to sympathize with the poor programmer who needs to squeeze another microsecond off a tight loop, but sympathy alone won't relieve him from his plight. In addition to criticizing the short-sighted gang of compiler writers, one could figure out *how* to remove "unnecessary" restrictions in programming language design. Rubin thinks it is possible, :... :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. I would like very much if such a portable-assembler/medium-level-PL were to be proposed. I think Rubin has made his objections to the state of the art clear enough, but I don't think he has provided evidence to advance the idea that his desires are realizable. How about coming with a first cut of a language design, with supporting argument for the contention that it will be hardware-inspired and still portable? My personal guess is that, were he to try, Rubin would come out with a language in the general class of C/Bliss/BCPL. The exercise would be fruitful still: no more negative comments, once he realizes that language designers are not (totally) crazy, and that "progress in programming", if anything, means getting *away* from the vagaries of the hardware. Looking forward for the manual, Cesar -- Cesar Augusto Quiroz Gonzalez Department of Computer Science ...allegra!rochester!quiroz University of Rochester or Rochester, NY 14627 quiroz@cs.rochester.edu
bobmon@iuvax.cs.indiana.edu ([bob, mon]) (03/09/88)
In article <600@ihnet.ATT.COM> tjr@ihnet.ATT.COM (Tom Roberts) writes: >Dave Burton writes: >>> [omitted discussion of #asm ... ] >>>Do *not* mix languages in a single source file. The chalkboard in our hardware lab had an "interesting" instruction scribbled on it today: jmp *XEDIT I'd love to see this one in action.
daveb@geac.UUCP (David Collier-Brown) (03/09/88)
In article <7501@sol.ARPA> quiroz@cs.rochester.edu (Cesar Quiroz) writes: | Herman Rubin has consistently criticized in this group high-level | language designers/implementors for not producing the portable | assembler he wishes to use [several paragraphs deleted] | My personal guess is that, were he to try, Rubin would come out with | a language in the general class of C/Bliss/BCPL. The exercise would | be fruitful still: no more negative comments, once he realizes that | language designers are not (totally) crazy, and that "progress in | programming", if anything, means getting *away* from the vagaries of | the hardware. Published last year (or maybe the one before) in Dr. Dobb's: a subset-language of C which was in fact an assembler for a 68k machine. And the idea is to get away from the vagaries without losing the capabilities. The latter is surprisingly hard, the turing machine notwithstanding. --dave (doesn't anyone read any more?) c-b -- David Collier-Brown. {mnetor yunexus utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
daveb@laidbak.UUCP (Dave Burton) (03/10/88)
In article <2424@geac.UUCP> daveb@geac.UUCP (David Collier-Brown) writes: > Published last year (or maybe the one before) in Dr. Dobb's: a >subset-language of C which was in fact an assembler for a 68k >machine. The article you mention is Dr. Dobb's Journal ... #111, January 1986. Ed Ream was/is the author. He called his language PL/68k. The magazine titled the article "C becomes assembly language". -- --------------------"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