From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <54fc0f1102d30ae5933e78e2e391032f@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] speaking of kenc
Date: Sat,  5 May 2007 21:13:11 +0200
From: lucio@proxima.alt.za
In-Reply-To: <93127bddd2e7438f98ca3a31f291ced2@coraid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Topicbox-Message-UUID: 5ad2e13e-ead2-11e9-9d60-3106f5b1d025

> 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