From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Blue Swirl <blauwirbel@gmail.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Richard Henderson <rth@twiddle.net>
Subject: Re: [Qemu-devel] Re: Compile files only once: some planning
Date: Wed, 24 Mar 2010 17:27:57 +0000 [thread overview]
Message-ID: <201003241727.57800.paul@codesourcery.com> (raw)
In-Reply-To: <4BAA3B53.5030606@redhat.com>
> >>>> 1) make CPUState define only common fields. Include CPUState at the
> >>>> beginning of each per-target CPUXYZState.
> >>>
> >>> Irritatingly, the common fields contain quite big TLBs. And the
> >>> offsets from the start of env affect the compactness of the code
> >>> generated from TCG. We really really want the general registers
> >>> to come first to make sure that those offsets fit the host's
> >>> reg+offset addressing mode.
> >>
> >> What about adding a 512-bytes (or more) block or something like that at
> >> the beginning of CPUState with a union, so you can put the per-target
> >> stuff there?
> >
> > Is it really worth the hassle? Anything touching CPUState is probably
> > going to be CPU specific anyway.
>
> qemu-timer.c, hw/dma.c is not and these are the first two files I looked
> at. translate-all.c is the third, and it is except for a trivial cleanup.
The use in hw/dma.c is incorrect. See previous discussion about how
qemu_bh_schedule_idle needs to go away.
I'm also unconvinced by your numbers. My i386-softmmu/ directory contains only
43 object files, most of are device emulation and don't touch CPU state at
all. arm-softmmu/ contains a good number more, but that's mostly board init
(which needs to know which CPU it's creating), and devices that are only used
by one board so noone's bothered to move them into libhw.
Paul
next prev parent reply other threads:[~2010-03-24 17:28 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-23 21:43 [Qemu-devel] Compile files only once: some planning Blue Swirl
2010-03-24 9:17 ` [Qemu-devel] " Juan Quintela
2010-03-24 17:56 ` Blue Swirl
2010-03-24 19:28 ` Juan Quintela
2010-03-24 22:47 ` Paul Brook
2010-03-24 22:57 ` Anthony Liguori
2010-03-25 3:08 ` Jamie Lokier
2010-03-25 2:54 ` Jamie Lokier
2010-03-24 9:47 ` Paolo Bonzini
2010-03-24 11:19 ` Richard Henderson
2010-03-24 14:45 ` Paolo Bonzini
2010-03-24 14:56 ` Paul Brook
2010-03-24 16:18 ` Paolo Bonzini
2010-03-24 17:27 ` Paul Brook [this message]
2010-03-24 17:07 ` Richard Henderson
2010-03-24 20:12 ` Richard Henderson
2010-03-24 18:00 ` Blue Swirl
2010-03-24 19:39 ` Michael S. Tsirkin
2010-03-24 20:05 ` Blue Swirl
2010-03-24 20:08 ` Michael S. Tsirkin
2010-03-24 20:24 ` Blue Swirl
2010-03-24 20:24 ` Michael S. Tsirkin
2010-03-24 20:32 ` Blue Swirl
2010-03-24 20:28 ` Anthony Liguori
2010-03-24 21:00 ` Aurelien Jarno
2010-03-24 22:33 ` Paul Brook
2010-03-24 22:50 ` Anthony Liguori
2010-03-24 23:05 ` Paul Brook
2010-03-24 23:07 ` Anthony Liguori
2010-03-25 8:21 ` Michael S. Tsirkin
2010-03-25 12:01 ` Paul Brook
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=201003241727.57800.paul@codesourcery.com \
--to=paul@codesourcery.com \
--cc=blauwirbel@gmail.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rth@twiddle.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).