thank you for replying for me. you know my mindset well. i'm not enthused by inline either. things were different when function calls were expensive but inlines just blow your cache for little benefit and incite incivility, bloating binaries.
perkin-elmer (remember them?) once released a fortran compiler that inlined eveything (before fortran had recursion). this was very impressive for some benchmarks but for any real program you ended up with real fat-ass binaries - they added paging of page tables to cope. what a great product. brucee On 5/6/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 1. in space-restricted environments like the mbr or pbs. > > 2. to deal with stuff outside the scope of higher-level > languages. for example, [rwm]fence, ia msrs. test-and-set. > > 3. small embedded systems. 1 and 3 are not really that different, so you're down to two examples. C is OK for newer embedded systems (microcontrollers), older ones are what they are and ASM may well be the way to go. But even there, ASM is often just the lazy way rather than the more economical way. I have a feeling brucee will point out that the gain in efficiency in using ASM is insufficient to justify the additional costs in complexity and error potential. There certainly are tasks that cannot be done in C, like test-and-set and, say, context switches, but such specialised tasks should either live in a C-callable library or ought to be added to the optimisation pass(es) in a C compiler, rather than encourage programmers to drop into assembler at the drop of a hat, often merely for the benefit of re-inventing a common operation. That said, lack of the ability to "inline" functions may be perceived as a drawback of the Plan 9 C compiler. As I mentioned elsewhere, the loader may well be the place where "inline" could be put to best use. ++L
