From: David Mosberger <davidm@napali.hpl.hp.com>
To: Jes Sorensen <jes@wildopensource.com>
Cc: "Siddha, Suresh B" <suresh.b.siddha@intel.com>,
"Christoph Hellwig" <hch@infradead.org>,
"Andrew Morton" <akpm@osdl.org>,
"Linus Torvalds" <torvalds@osdl.org>,
<linux-kernel@vger.kernel.org>,
"Nakajima, Jun" <jun.nakajima@intel.com>,
"Mallick, Asit K" <asit.k.mallick@intel.com>
Subject: Re: [Patch] asm workarounds in generic header files
Date: Tue, 9 Sep 2003 13:25:28 -0700 [thread overview]
Message-ID: <16222.14136.21774.211178@napali.hpl.hp.com> (raw)
In-Reply-To: <m3llsxivva.fsf@trained-monkey.org>
>>>>> On 09 Sep 2003 15:51:05 -0400, Jes Sorensen <jes@wildopensource.com> said:
Jes> I actually think this is degrading the code rather then
Jes> improving it. Right now the various macros are located in the
Jes> include/asm-<foo> directory next to the items where they are
Jes> used. Moving it all into one big catch-all assembly file makes
Jes> it a lot harder to read things and debug the code. I already
Jes> took a look at the changes that went into the ia64 part of the
Jes> tree and I really think that was a step backwards.
In my opinion, moving all the asm-stuff greatly improved readability
of the source code. Especially for folks who are not intimately
familiar with GCC asm syntax (which is hairy _and_ platform-specific).
Jes> In terms of compiling the Linux kernel, I will argue that the
Jes> Intel compiler is broken if it cannot handle inline
Jes> assembly. Inline assembly is just too fundamental a feature for
Jes> the kernel. This is totally ignoring the question of whether
Jes> one should be compiling the kernel with non-GCC in the first
Jes> place.
I think the jury is out on this one. Clearly it's a huge benefit if
you can make do without inline asm. GCC has to make lots of
worst-case assumptions whenever it encounters an asm statement and,
due to macros and inlining, the asm statements are not just hidden in
a few leaf routines. In my opinion, this experiment is at least worth
a try. If it succeeds, great, if it fails (e.g., the Intel compiler
folks fail to keep up with the kernel), all we have to do is
rm intel_intrin.h.
--david
next prev parent reply other threads:[~2003-09-09 20:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-09-09 19:34 Siddha, Suresh B
2003-09-09 19:51 ` Jes Sorensen
2003-09-09 20:25 ` David Mosberger [this message]
2003-09-09 20:33 ` Linus Torvalds
2003-09-09 21:16 ` Sam Ravnborg
2003-09-09 23:44 ` David Mosberger
2003-09-10 16:22 ` Jes Sorensen
2003-09-10 17:02 ` David Mosberger
-- strict thread matches above, loose matches on Subject: below --
2003-09-10 5:51 Nakajima, Jun
2003-09-10 4:50 Siddha, Suresh B
2003-09-10 5:08 ` Andrew Morton
2003-09-09 1:04 Siddha, Suresh B
2003-09-09 2:27 ` Jes Sorensen
2003-09-09 6:40 ` Christoph Hellwig
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=16222.14136.21774.211178@napali.hpl.hp.com \
--to=davidm@napali.hpl.hp.com \
--cc=akpm@osdl.org \
--cc=asit.k.mallick@intel.com \
--cc=davidm@hpl.hp.com \
--cc=hch@infradead.org \
--cc=jes@wildopensource.com \
--cc=jun.nakajima@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=suresh.b.siddha@intel.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®