public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eli Carter <eli.carter@inet.com>
To: John Bradford <john@grabjohn.com>
Cc: nuno.silva@vgertech.com, torvalds@transmeta.com,
	linux-kernel@vger.kernel.org, samphan@thai.com, vojtech@suse.cz
Subject: Re: Crusoe's persistent translation on linux?
Date: Fri, 20 Jun 2003 11:49:22 -0500	[thread overview]
Message-ID: <3EF33B12.7070901@inet.com> (raw)
In-Reply-To: 200306201040.h5KAerPK000431@81-2-122-30.bradfords.org.uk

John Bradford wrote:
>>The translations are usually _better_ than statically compiled native 
>>code (because the whole CPU is designed for speculation, and the static 
>>compilers don't know how to do that), and thus going to native mode is not 
>>necessarily a performance improvement.
> 
> 
> Would it be possible, (with relevant documentation), to tune the code
> morphing software for optimum performance of code generated by a
> specific compiler, though?
> 
> If a particular version of GCC favours certain constructs and uses
> particular sets of registers for a given piece of code, couldn't we
> optimise for those cases, at the expense of others?  Maybe a
> particular compiler doesn't use certain X86 instructions at all, and
> these could be eliminated altogether?
> 
> It's not unlikely that an entirely open source system could have all
> code compiled with the same compiler, and so maybe we can use this to
> avoid implementing expensive corner cases in the CPU, because we're
> never going to trigger them.

Hmm... basically you want to trim the x86 instruction set to get closer 
to RISC mentality.  Interesting.  gcc may already do that to some extent 
by not using the really complex instructions.  If that is the case, 
dropping those instructions might give some room for testing some of its 
possible benefits.  I doubt restricting the registers used by some 
instructions would help... I've heard comments that the x86 is 
register-starved enough already.

Have fun,

Eli
--------------------. "If it ain't broke now,
Eli Carter           \                  it will be soon." -- crypto-gram
eli.carter(a)inet.com `-------------------------------------------------


  reply	other threads:[~2003-06-20 16:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-06-20 10:40 Crusoe's persistent translation on linux? John Bradford
2003-06-20 16:49 ` Eli Carter [this message]
2003-06-20 16:56   ` Jeff Garzik
2003-06-20 17:46     ` dean gaudet
  -- strict thread matches above, loose matches on Subject: below --
2003-06-20 19:35 John Bradford
2003-06-19 16:37 Samphan Raruenrom
2003-06-19 18:03 ` Vojtech Pavlik
2003-06-19 19:51   ` Samphan Raruenrom
2003-06-20  0:02     ` Nuno Silva
2003-06-20  0:16       ` Linus Torvalds
2003-06-20  2:08         ` Nuno Silva
2003-06-20  9:08         ` Xavier Bestel
2003-06-20  9:33           ` Nick Piggin
2003-06-20 14:08           ` Henning P. Schmiedehausen
2003-06-20 15:38           ` Linus Torvalds
2003-06-20 12:05         ` Samphan Raruenrom

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=3EF33B12.7070901@inet.com \
    --to=eli.carter@inet.com \
    --cc=john@grabjohn.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nuno.silva@vgertech.com \
    --cc=samphan@thai.com \
    --cc=torvalds@transmeta.com \
    --cc=vojtech@suse.cz \
    /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