qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: Rob Landley <rob@landley.net>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] qemu vs gcc4
Date: Wed, 1 Nov 2006 17:01:59 +0000	[thread overview]
Message-ID: <200611011702.00547.paul@codesourcery.com> (raw)
In-Reply-To: <200611011134.23937.rob@landley.net>

On Wednesday 01 November 2006 16:34, Rob Landley wrote:
> On Tuesday 31 October 2006 10:22 pm, Paul Brook wrote:
> > > > and glue them together like we do with dyngen. However once you've
> > > > done that you've implemented most of what's needed for fully dynamic
> > > > qops, so it doesn't really seem worth it.
> > >
> > > I missed a curve.  What's "fully dynamic qops"?  (There's no
> > > translation cache?)
> >
> > I mean all the qop stuff I've implemented.
>
> Still lost.  Where does the "fully dynamic" part come in?

Generating code instead in blindly glueing together precompiled fragments.

> > > Any idea where I can get a toolchain that can output a "hello world"
> > > program for m68k nommu?  (Or perhaps you have a statically linked
> > > "hello world" program for the platform lying around?)
> >
> > Funnily enough I do :-)
> > http://www.codesourcery.com/gnu_toolchains/coldfire/
>
> Woot.
>
> This download page was designed by your company's legal department, I take
> it? (There's no such thing as GNU/Linux, and you don't have to accept the
> GPL because it's based on copyright law, not contract law, so "informed
> consent" is not the basis for enforcement.)

I suspect it's more to do with due diligence on our part. While it might not 
have any legal meaning on its own, it makes it much harder for people to 
claim they infringed copyright accidentally. 

> > Lazy flag evaluation is where you don't bother calculating the actual
> > flags when executing the flag-setting instruction. Instead you save the
> > operands/result and compute the flags when you actually need them.
>
> Such as when the computation's in a loop but you only test after exiting
> the loop for other reasons?  I'd have to see examples to figure out how it
> would make sense to optimize that...

Ys, or when only some flags are used. eg:

 add %eax, %ebx
 adc %cex, %edx

The adc instruction only uses the carry flag, then clobbers all the rest. A 
naive implementation would evaluate all the flags after the add. With Lazy 
evaluation we evaluate just the carry flag before the adc, and know we don't 
have to bother calculating the other flags. It also avoids having to evaluate 
the flags at a TB boundary.

> > > The exponential complexity is if you have to write different code for
> > > each combination of host and target.  If every target disassembles to
> > > the same set of target QOPs, then you could have a hand-written
> > > assembly version of each QOP for each host platform, and still have N
> > > rather than N^2 of them.
> >
> > Right, but by the time you've got everything to use the same set of ops
> > you may as well teach qemu how to generate code instead of using potted
> > fragments.
>
> I'm thinking of "here's the code for performing this QOP on this
> processor". I'm not sure what distinction you're making.

The difference is whether qemu knows how to generate code for that target, or 
is blindly glueing binary blobs together.

Paul

  reply	other threads:[~2006-11-01 17:02 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-20 18:53 [Qemu-devel] qemu vs gcc4 K. Richard Pixley
2006-10-22 22:06 ` Johannes Schindelin
2006-10-23  8:16   ` Martin Guy
2006-10-23 12:20     ` Paul Brook
2006-10-23 13:59       ` Avi Kivity
2006-10-23 14:10         ` Paul Brook
2006-10-23 14:28           ` Avi Kivity
2006-10-23 14:31             ` Paul Brook
2006-10-23 14:35               ` Avi Kivity
2006-10-23 17:41     ` K. Richard Pixley
2006-10-23 17:58       ` Paul Brook
2006-10-23 18:04         ` K. Richard Pixley
2006-10-23 18:20           ` Laurent Desnogues
2006-10-23 18:37           ` Paul Brook
2006-10-24 23:39             ` Rob Landley
2006-10-25  0:24               ` Paul Brook
2006-10-25 19:39                 ` Rob Landley
2006-10-26 18:09                   ` Daniel Jacobowitz
2006-10-31 16:53             ` Rob Landley
2006-10-31 19:02               ` Paul Brook
2006-10-31 20:41                 ` Rob Landley
2006-10-31 22:08                   ` Paul Brook
2006-10-31 22:31                     ` Laurent Desnogues
2006-10-31 23:00                       ` Paul Brook
2006-11-01  0:00                     ` Rob Landley
2006-11-01  0:29                       ` Paul Brook
2006-11-01  1:51                         ` Rob Landley
2006-11-01  3:22                           ` Paul Brook
2006-11-01 16:34                             ` Rob Landley
2006-11-01 17:01                               ` Paul Brook [this message]
2006-10-31 23:17                 ` Rob Landley
2006-11-01  0:01                   ` Paul Brook
2006-10-30  4:35         ` Rob Landley
2006-10-30 14:56           ` Paul Brook
2006-10-30 16:31             ` Rob Landley
2006-10-30 16:50               ` Paul Brook
2006-10-30 22:54                 ` Stephen Torri
2006-10-30 23:13                   ` Paul Brook
2006-10-23  1:27 ` Rob Landley
2006-10-23  1:44   ` Paul Brook
2006-10-23  1:45   ` Johannes Schindelin
2006-10-23 17:53     ` K. Richard Pixley
2006-10-23 18:08     ` Rob Landley

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=200611011702.00547.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    --cc=rob@landley.net \
    /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).