about void voids (Re: efopen.c)

[Pat Shanahan]

In article <284 at 3comvax.UUCP> mikes at 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 at nosc