Re: [9fans] speaking of kenc

["Bruce Ellis" <bruce.ellis@gmail.com>]

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, lucio@proxima.alt.za <lucio@proxima.alt.za> 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
>
>