mash@mips.UUCP (John Mashey) (06/19/87)
In article <21211@sun.uucp> guy%gorodish@Sun.COM (Guy Harris) writes: >> >asm("<assembler code>"); >> Isn't this spo'sta be apart of the "Standard C". I seem to remember >> it being metioned in the K&R. >It is absolutely NOT supposed to be in standard C! .... Guy gives good list of reasons why not.... In support of at least one, our code generator normally passes its output to the assembler in binary form, although assembler can be generated. Use of asm would of course force the less efficient form, or force the code generator to parse the asm statement itself, a distasteful thought. More important: And finally, "asm" and global-optimizing compilers are fairly contradictory. A good optimizer: a) Mostly ignores register declarations. It allocates registers as appropriate. The same variable may well appear in several different places during the code. b) May, given slightly different source code, rearrange the register use substantially. c) Will find it VERY hard to figure out what an arbitrary "asm statement" is doing, in terms of side-effects. Finally, some questions: a) What global optimizing C compilers do people use out there? Known ones: MIPS, Green Hills, Sun's, DEC [newest Ultrix one, I think], Multiflow, Tartan Labs, newest IBM one for RT PC, HP's Spectrum compiler. Any others? Any for PC's? b) What global optimizers do people use to compile their UNIX kernels? i.e., which of them have implemented "volatile", without which device drivers are not easy. Having used both asm and serious optimizers, I know which I'd rather have. -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
bright@dataio.Data-IO.COM (Walter Bright) (06/23/87)
In article <464@winchester.UUCP> mash@winchester.UUCP (John Mashey) writes:
<More important:
<And finally, "asm" and global-optimizing compilers are fairly
<contradictory. A good optimizer:
< a) Mostly ignores register declarations. It allocates
< registers as appropriate.
Datalight C can even allocate more than one variable to a specific register,
if their usages do not overlap. This is known as 'register allocation by
coloring'.
< b) May, given slightly different source code, rearrange the
< register use substantially.
< c) Will find it VERY hard to figure out what an arbitrary
< "asm statement" is doing, in terms of side-effects.
It's not that hard. Assuming that the asm doesn't contain jumps out of
or into itself, flow analysis can be done over asm statements by assuming
that they can but not necessarilly do modify everything.
<Finally, some questions:
< a) What global optimizing C compilers do people use out there?
< Known ones: MIPS, Green Hills, Sun's, DEC [newest Ultrix
< one, I think], Multiflow, Tartan Labs, newest IBM one
< for RT PC, HP's Spectrum compiler.
< Any others? Any for PC's?
The Datalight C compiler is a globally optimizing compiler. It does
most of the classic global optimizations that depend on data flow analysis.
For example, it does constant propagation, copy propagation, very busy
expressions, partially redundant expressions, loop induction variables,
register allocation by coloring, etc.
Disclaimer: I have no association with Datalight other than the fact that
I wrote the compiler and receive money for it.