mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Mosberger <davidm@napali.hpl.hp.com>
To: Jes Sorensen <jes@wildopensource.com>
Cc: davidm@hpl.hp.com, <linux-kernel@vger.kernel.org>
Subject: Re: [Patch] asm workarounds in generic header files
Date: Wed, 10 Sep 2003 10:02:40 -0700	[thread overview]
Message-ID: <16223.22832.21582.762891@napali.hpl.hp.com> (raw)
In-Reply-To: <m3d6e8ipf6.fsf@trained-monkey.org>

>>>>> On 10 Sep 2003 12:22:37 -0400, Jes Sorensen <jes@wildopensource.com> said:

  Jes> I think this really depends on what you are trying to debug. If
  Jes> you expect the macros to do exactly what they are described to
  Jes> be doing then I'd agree. However every so often when you look
  Jes> up the macros you really want to look at the details what they
  Jes> are actually doing or even compare them to another arch's
  Jes> implementation to make sure they are behaving the same. At
  Jes> least thats my experience.

That's true for some, but not others.  For example, I'd say that
things like getreg() and setreg() are pretty intuitive.

  Jes> I personally think it's unrealistic to think one can try and
  Jes> debug things in include/asm without being able to read the
  Jes> assembly output in the first place.

Assembly output != GCC asm statements.  There are lots of
assembly-savy folks that have no clue how to read/interpret the GCC
asm syntax.  Those folks have the option of either generating an
assembly file or disassembling the resulting object file.  Both
approaches would let them read the resulting code without having to
know exactly how the asm statement (or intrinsic) works.

  David> I think the jury is out on this one.  Clearly it's a huge
  David> benefit if you can make do without inline asm.  GCC has to
  David> make lots of worst-case assumptions whenever it encounters an
  David> asm statement and, due to macros and inlining, the asm
  David> statements are not just hidden in a few leaf routines.

  Jes> Reducing the amount of inline asm in the kernel would be a good
  Jes> thing. It is cetainly one of those things that have been abused
  Jes> way beyond it's intent.

Agreed.

	--david

  reply	other threads:[~2003-09-10 17:02 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
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 [this message]
  -- 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=16223.22832.21582.762891@napali.hpl.hp.com \
    --to=davidm@napali.hpl.hp.com \
    --cc=davidm@hpl.hp.com \
    --cc=jes@wildopensource.com \
    --cc=linux-kernel@vger.kernel.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®