mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "David S. Miller" <davem@davemloft.net>
To: jengelh@linux01.gwdg.de
Cc: vda@ilport.com.ua, linux-kernel@vger.kernel.org
Subject: Re: www.softpanorama.org: sparc_vs_x86 fun
Date: Thu, 04 May 2006 15:51:25 -0700 (PDT)	[thread overview]
Message-ID: <20060504.155125.68091905.davem@davemloft.net> (raw)
In-Reply-To: <Pine.LNX.4.61.0605041322070.24957@yvahk01.tjqt.qr>

From: Jan Engelhardt <jengelh@linux01.gwdg.de>
Date: Thu, 4 May 2006 13:31:37 +0200 (MEST)

> while on SPARC, it takes 6 instructions (of course, being RISC makes it 
> execute differently than x64)
> 
>     sethi %g1, $some_upper_bits
>     or %g1, $next_bitgroup
>     (shift-left)
>     or %g1, $next_bitgroup
>     (shift-left)
>     or %g1, $last_bitgroup
> 
> BTW, T1 is cool, but that the 1U version only has space for 1 disk is 
> pretty limiting :/

This example instruction sequence is incredibly misleading.

First of all, the vast majority of constants can be loaded in 1 to 3
instruction sequences.  I know this because I wrote the code that
emits 64-bit constant loading in the sparc backend of gcc and I've
watched how it tends to work when compiling real code.

Yes, the code density sucks on sparc compared to any x86 variant,
32-bit or 64-bit, but there is no need to exaggerate.

For symbolic references, it depends upon the code model and whether
you are generating PIC or not.  If you use the 32-bit medlow code
model, non-PIC, which is the default for apps being compiled under
sparc64/Linux, it's two instructions to load a symbol address.

The sequence gets progressively larger as you move onto the medmid
and midany code models.


  reply	other threads:[~2006-05-04 22:51 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-04  9:24 Denis Vlasenko
2006-05-04 10:56 ` jimmy
2006-05-04 11:41   ` Dagfinn Ilmari Mannsåker
2006-05-04 18:59     ` Dmitry Torokhov
2006-05-04 11:31 ` Jan Engelhardt
2006-05-04 22:51   ` David S. Miller [this message]
2006-05-09 14:39   ` Bill Davidsen
2006-05-12 15:18     ` Jan Engelhardt

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=20060504.155125.68091905.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=jengelh@linux01.gwdg.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=vda@ilport.com.ua \
    /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

Powered by JetHome