Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site celerity.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!lll-crg!lll-lcc!vecpyr!amd!pesnta!pyramid!gould9!ncr-sd!sdcc6!celerity!ps From: ps@celerity.UUCP (Pat Shanahan) Newsgroups: net.lang.c Subject: Re: Re: about void voids (Re: efopen.c) Message-ID: <382@celerity.UUCP> Date: Thu, 21-Nov-85 16:28:17 EST Article-I.D.: celerity.382 Posted: Thu Nov 21 16:28:17 1985 Date-Received: Sun, 24-Nov-85 07:22:08 EST References: <6679@boring.UUCP> <25500120@ISM780B.UUCP> <284@3comvax.UUCP> Reply-To: ps@celerity.UUCP (Pat Shanahan) Organization: Celerity Computing, San Diego, Ca. Lines: 56 In article <284@3comvax.UUCP> mikes@3comvax.UUCP (Mike Shannon) writes: ... > >One thing which many Unix compilers support is the 'asm' statement, that is: >proc() >{ > asm("mov r0, r1"); >} > the effect of the 'asm' procedure call is not to generate code. >Instead, the string is passed 'directly' thru as assembly language in the >generated output. This allows the programmer to generate assembly >language directly. Not only is it machine specific, but it is also >dependent on the optimizer in the compiler. > I'd sure like to see someone defend this particularly disgusting >(but supported on our 4.1bsd system) "feature"! >-- > Michael Shannon {ihnp4,hplabs}!oliveb!3comvax!mikes While I am not prepared to defend the use of "asm" in normal application or utility programming, I have maintained it in a C compiler port and added a minor enhancement, so I think I should defend its presence in the compiler. Any operating system has to have some functions that are highly machine dependent. The functions may manipulate the state of paging tables, or control I/O activity, or save and restore the process state. Some of these functions will have to be implemented entirely in assembly language. However, there are functions that can be implemented substantially in C, if the programmer can insert a small number of explicit assembly language statements. These functions often cannot be subdivided without an unacceptable performance overhead. Without the "asm" feature, these functions would all have to be implemented entirely in assembly language. With the "asm" feature, the programmer who is responsible for implementing a function can decide which language to use. I see a well-implemented "asm" as a tool for reducing the volume of assembly language code in the operating system. Similar situations can arise in diagnostics or timing measurement. I think that "asm" should only be used in functions that meet both of the following conditions. 1) The function is inherently machine-dependent, so that it would have to be re-written to port it to a substantially different machine. 2) The alternative to using "asm" is to write it entirely in assembly language. -- ps (Pat Shanahan) uucp : {decvax!ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ps arpa : sdcsvax!celerity!ps@nosc