From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HZz4i-0006we-Ba
	for qemu-devel@nongnu.org; Fri, 06 Apr 2007 20:46:40 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HZz4h-0006wI-MV
	for qemu-devel@nongnu.org; Fri, 06 Apr 2007 20:46:39 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HZz4h-0006w8-8n
	for qemu-devel@nongnu.org; Fri, 06 Apr 2007 20:46:39 -0400
Received: from static-71-162-243-5.phlapa.fios.verizon.net ([71.162.243.5]
	helo=grelber.thyrsus.com) by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <rob@landley.net>) id 1HZz19-0007Ht-BH
	for qemu-devel@nongnu.org; Fri, 06 Apr 2007 20:42:59 -0400
From: Rob Landley <rob@landley.net>
Subject: Re: [Qemu-devel] [RFC/experimental patch] qemu (x86_64 on x86_64
	-no-kqemu) compiles with gcc4 and works
Date: Fri, 6 Apr 2007 17:04:21 -0400
References: <200703241850.03116.axel.zeuner@gmx.de>
	<46067BD5.1050609@qumranet.com>
	<200703261914.54274.axel.zeuner@gmx.de>
In-Reply-To: <200703261914.54274.axel.zeuner@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200704061704.21239.rob@landley.net>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org
Cc: Axel Zeuner <axel.zeuner@gmx.de>

On Monday 26 March 2007 1:14 pm, Axel Zeuner wrote:
> Hi Avi,
> On Sunday 25 March 2007 15:40, Avi Kivity wrote:
> > Axel Zeuner wrote:
> > > A full featured converter (cvtasm) has a lot of dependencies: it has to
> > > support all hosts (M) (with all assembler dialects M') and all targets 
N,
> > > i.e. in the worst case one would end with M'x N variants of it, or M x N
> > > if one supports only one assembler dialect per host.  It is clear, that
> > > the number of variants is one of the biggest disadvantages of such an
> > > approach.
> >
> > Perhaps a mixed approach can be made for gradual conversion: for
> > combinations where cvtasm has been written, use that.  Where that's
> > still to be done, have dyngen generate call instructions to the ops
> > instead of pasting the ops text directly.
> Perhaps, but I am not sure, if the changes required for generating calls 
with 
> parameters to functions instead of copied code in dyngen are much smaller 
> than hand written code generators. Furthermore one would surely lose some 
> performance.
> 
> Kind Regards
> Axel

On a related note, I have this vague urge from time to time to get qemu to 
build with tcc.

Haven't even come close to making it work yet, of course... :)

Rob
-- 
Penguicon 5.0 Apr 20-22, Linux Expo/SF Convention.  Bruce Schneier, Christine 
Peterson, Steve Jackson, Randy Milholland, Elizabeth Bear, Charlie Stross...