levy@ttrdc.UUCP (Daniel R. Levy) (11/28/85)
In article <86900003@haddock.UUCP>, lee@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
jsdy@hadron.UUCP (Joseph S. D. Yao) (11/30/85)
First off: the best way to find out for a given C compiler on a
given machine (which is all you want, anyway, since asm's are
inherently non-portable) is to ask the compiler. Do a cc -S
(cc -S -O if you like) to get an assembler output.
Most C compilers I have run into seem to (note all the hedging) put
register variables into the highest free register first. E.g., on
the VAX skip PC, SP, FP, AP, and start with R11. Most C compilers
then allow you down to R6 or R5. On the PDP-11, one skipped PC, SP,
and FP, and had R4-R2. The 80X86 is (characteristically) a total
mess: SI and DI are often used, as the closest to real GP registers;
although some will use DX, CX, and BX and skip the optimisations
that using them in-line sometimes bring. The M680X0 uses the VAX
model, with the interesting twist of address + data registers. ...
Static and extern data typically has the same name as in the C
program, but with an underscore pre-pended: but not a few have chosen
to change even this simple rule.
Auto's tend to be put on the stack, with the first-declared closest
to the head of the stack and later vars further down. In the back
of my head there's something nagging at me that there are machines
that do it with the last-declared near the top of the stack. Either
way, array elements are always in the correct order.
--
Joe Yao hadron!jsdy@seismo.{CSS.GOV,ARPA,UUCP}