public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Cort Dougan <cort@fsmlabs.com>
To: Linus Torvalds <torvalds@transmeta.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Why Plan 9 C compilers don't have asm("")
Date: Fri, 6 Jul 2001 14:02:20 -0600	[thread overview]
Message-ID: <20010706140220.A6572@ftsoj.fsmlabs.com> (raw)
In-Reply-To: <200107040337.XAA00376@smarty.smart.net> <20010704002436.C1294@ftsoj.fsmlabs.com> <9hvjd4$1ok$1@penguin.transmeta.com> <20010706023835.A5224@ftsoj.fsmlabs.com> <9i50uf$tla$1@penguin.transmeta.com>
In-Reply-To: <9i50uf$tla$1@penguin.transmeta.com>; from torvalds@transmeta.com on Fri, Jul 06, 2001 at 06:44:31PM +0000

Yes, that was not easy to miss.  I was simply being clear.  The plan9
compiler, thus its take on inline asm, doesn't run on ia64 and alpha as far
as I can see from the latest release.

} NONE of my examples were about the x86.
} 
} I gave the alpha as a specific example.  The same issues are true on
} ia64, sparc64, and mips64.  How more "modern" can you get? Name _one_
} reasonably important high-end CPU that is more modern than alpha and
} ia64.. 
} 
} On ia64, you probably end up with function calls costing even more than
} alpha, because not only does the function call end up being a
} synchronization point for the compiler, it also means that the compiler
} cannot expose any parallelism, so you get an added hit from there.  At
} least with other CPU's that find the parallelism dynamically they can do
} out-of-order stuff across function calls. 

Yes, that's how I saw it didn't relate to the topic at hand.  I suggested
measurement rather than theory to determine whether the branch washes out
or not.  "Everyone knows" is a much weaker statement than "I can show".

} Did you READ my mail at all?

I definitely agree there.  If you need an instruction or two that the
compiler doesn't offer then it's a loss to call a function and inline asm
is worthwhile.  If this is a common enough case it's worth the compiler
adding inline asm support.  I'm not sure how often that is.  My own
subjective experience has been that calls to such code are rare enough that
they fall well into the realm of optimization the uncommon case.

I've used inline asm gratuitously in linux (it's peppered all over the ppc
code) because I had the feature.  I don't think that's a strong argument
for adding it to a compiler that doesn't support it, though.

} There are lots of good arguments for function calls: they improve icache
} when done right, but if you have some non-C-semantics assembler sequence
} like "cli" or a spinlock that you use a function call for, that would
} _decrease_ icache effectiveness simply because the call itself is bigger
} than the instruction (and it breaks up the instruction sequence so you
} get padding issues). 

  reply	other threads:[~2001-07-06 20:01 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-07-04  3:37 Why Plan 9 C compilers don't have asm("") Rick Hohensee
2001-07-04  3:36 ` Olivier Galibert
2001-07-04  6:24   ` Cort Dougan
2001-07-04  8:03     ` H. Peter Anvin
2001-07-04 17:22     ` Linus Torvalds
2001-07-06  8:38       ` Cort Dougan
2001-07-06 11:43         ` David S. Miller
2001-07-06 18:44         ` Linus Torvalds
2001-07-06 20:02           ` Cort Dougan [this message]
2001-07-08 21:55           ` Victor Yodaiken
2001-07-08 22:28             ` Alan Cox
2001-07-08 22:29             ` David S. Miller
2001-07-09  1:22             ` Johan Kullstam
2001-07-21 22:10       ` Richard Henderson
2001-07-22  3:43         ` Linus Torvalds
2001-07-22  3:59           ` Mike Castle
2001-07-22  6:49           ` Richard Henderson
2001-07-22  7:44             ` Linus Torvalds
2001-07-22 15:53               ` Richard Henderson
2001-07-22 19:08                 ` Linus Torvalds
2001-07-04  7:15 ` pazke
2001-07-04 17:32 ` Don't feed the trooll [offtopic] " Ben LaHaise
2001-07-05  1:02 ` Michael Meissner
2001-07-05  1:54   ` Rick Hohensee
2001-07-05 16:54     ` Michael Meissner
  -- strict thread matches above, loose matches on Subject: below --
2001-07-04 10:10 Rick Hohensee
2001-07-05  3:26 Rick Hohensee
2001-07-06 17:24 Rick Hohensee
2001-07-06 23:54 ` David S. Miller
2001-07-07  0:16   ` H. Peter Anvin
2001-07-07  0:37     ` David S. Miller
2001-07-07  6:16 Rick Hohensee
     [not found] <mailman.994629840.17424.linux-kernel2news@redhat.com>
2001-07-09  0:08 ` Pete Zaitcev
2001-07-09  0:28   ` Victor Yodaiken
2001-07-09  3:03 Rick Hohensee
2001-07-23  4:39 Rick Hohensee

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=20010706140220.A6572@ftsoj.fsmlabs.com \
    --to=cort@fsmlabs.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    /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