DragonFly kernel List (threaded) for 2004-01
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]
Re: systimer01.patch available for review.
47.GA1022@xxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 28
NNTP-Posting-Host: 62.90.149.2
X-Trace: 1075396899 crater_reader.dragonflybsd.org 185 62.90.149.2
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:3529
Joerg Sonnenberger wrote:
> On Thu, Jan 29, 2004 at 01:50:21PM -0600, Dave Leimbach wrote:
>
>>How is it that a function written in assembly will create performance issues
>>over one written in C that uses inline assembly? Is it some human factor?
>
>
> The compiler can't optimize it e.g. via inling the call. Consider the
> example of inb/outb which needs one instruction. if this are written
> as separate function, you need a call/ret pair, instructions to save and
> read the arguments etc. therefore this is way slower.
Actually, there's nothing fundamental to prevent the compiler from
inlining a function if the source is not in the file being compiled.
In fact, Sun's Forte C compiler can optimise and inline functions across
multiple source files. With -xcrossfile, Sun CC analyses all the files
named on the command line as if they were a single source file.
Of course, this affects the way Makefiles are constructed, because
the files produced from cross-compilation must be used as one unit when
linking into a program. In particular, if one function is changed, all
the files must be recompiled (due to possible inlining
interdependencies).
AK
[
Date Prev][
Date Next]
[
Thread Prev][
Thread Next]
[
Date Index][
Thread Index]