asm

[Daniel R. Levy]

In article <86900003 at haddock.UUCP>, lee at haddock.UUCP writes:
>	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.
>I sometimes find an alternative to condition 1) along the following lines:
>	1a) the function is performance sensitive and can be significantly
>	improved in performance on a particular architecture by insertion of
>	small amounts of inline assembly code.
>For example, the operation performed by the IBM 370 "tr" instruction or the
>VAX "movtc" instruction can replace a loop in critical sections of otherwise
>ordinary C code.
>In these cases, of course, the asm() directive containing FOO assembly code
>should be embraced in "#if defined(foo)" and the equivalent C code compiled
>for architectures for which the asm() directives are not provided.

This sounds all nice, well, and good.  BUT--will someone please tell me how
one determines exactly where the compiler is going to put variables like
register variables (let alone those stored at 0Xblahblahblah)?  It looks
like a lot of magical hand waving, all I've seen about "oh, just do dowacky
with register 7, then hop back into your C code".  Is there another asm direc-
tive which will force this upon the compiler, so that register variable foo
is indeed found in register 7 when you expect, not in register 5 or 8 or
even in core [because the compiler didn't have enough registers, or the opti-
mizer migrated it in order to use that register for a loop variable instead]? 
If this is done empirically it sounds quite dangerous.  Are there manuals
available on this, which tell how the C compiler and optimizer for such and
such a system will be guaranteed to treat things in the assembly code it
creates, if you follow such and such rules in writing the code?

Thanks.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!ihnp4!ttrdc!levy