From: "Johan Kullstam" <kullstam@ne.mediaone.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Why Plan 9 C compilers don't have asm("")
Date: 08 Jul 2001 21:22:46 -0400 [thread overview]
Message-ID: <m2pubasxp5.fsf@euler.axel.nom> (raw)
In-Reply-To: <20010708155518.A23324@hq2>
In-Reply-To: <20010708155518.A23324@hq2>
Victor Yodaiken <yodaiken@fsmlabs.com> writes:
> On Fri, Jul 06, 2001 at 06:44:31PM +0000, Linus Torvalds wrote:
> > 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
>
> That seems amazingly dumb. You'd think a new processor design would
> optimize parallel computation over calls, but what do I know?
>
> > Most of these "unconditional branches" are indirect, because rather few
> > 64-bit architectures have a full 64-bit branch. That means that in
>
> This is something I don't get: I never understood why 32bit risc designers
> were so damn obstinate about "every instruction fits in 32 bits"
> and refused to have "call 32 bit immediate given in next word" not
> to mention a "load 32bit immediate given in next word".
> Note, the superior x86 instruction set has a 5 byte call immediate.
the 32 bit MIPS (R3K series, at least) has a 32 bit instruction which
loads a 16 bit immediate (which fits within the instruction itself).
thus to load a 32 bit number takes two instructions. since the
instructions are all 32 bits and must live on a multiple of 4 bytes,
this is as compact as you can get given the alignment constraint.
note that x86 is also fussy about alignment in various cases, e.g.,
double-precision floats.
> > 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).
>
> I think anywhere that you have inner loop or often used operations
> that are short assembler sequences, inline asm is a win - it's easy to
> show for example, that the Linux asm x86 macro semaphore down
> is three times as fast as
> a called version. I wish, however
> that GCC did not use a horrible overly complex lisplike syntax
lisp syntax is extremely simple. i am not sure what GCC does to make
it complex.
> and
> that there was a way to inline functions written in .S files.
>
> And the feature is way too easy to abuse - same argument here as in
> the threads argument.
> It's a far better thing to not need a semaphore at all than to rely
> on handcoded semaphore down to make your poorly synchronized design
> sort-of perform.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
J o h a n K u l l s t a m
[kullstam@ne.mediaone.net]
Don't Fear the Penguin!
next prev parent reply other threads:[~2001-07-09 1:24 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 18:44 ` Linus Torvalds
2001-07-06 20:02 ` Cort Dougan
2001-07-08 21:55 ` Victor Yodaiken
2001-07-08 22:28 ` Alan Cox
2001-07-09 1:22 ` Johan Kullstam [this message]
2001-07-08 22:29 ` David S. Miller
2001-07-06 11:43 ` David S. Miller
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
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=m2pubasxp5.fsf@euler.axel.nom \
--to=kullstam@ne.mediaone.net \
--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;
as well as URLs for NNTP newsgroup(s).