From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <775b8d190705051609k16942b85m39b30a567fc7c6f2@mail.gmail.com> Date: Sun, 6 May 2007 09:09:08 +1000 From: "Bruce Ellis" To: "Fans of the OS Plan 9 from Bell Labs" <9fans@cse.psu.edu> Subject: Re: [9fans] speaking of kenc In-Reply-To: <54fc0f1102d30ae5933e78e2e391032f@proxima.alt.za> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <93127bddd2e7438f98ca3a31f291ced2@coraid.com> <54fc0f1102d30ae5933e78e2e391032f@proxima.alt.za> Topicbox-Message-UUID: 5aea94d2-ead2-11e9-9d60-3106f5b1d025 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 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 > >