From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20)
	id 19Ox8M-0001po-Sw
	for qemu-devel@nongnu.org; Sun, 08 Jun 2003 06:10:42 -0400
Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20)
	id 19Ox8H-0001iP-V2
	for qemu-devel@nongnu.org; Sun, 08 Jun 2003 06:10:38 -0400
Received: from smtp5.wanadoo.fr ([193.252.22.27] helo=mwinf0402.wanadoo.fr)
	by monty-python.gnu.org with esmtp (Exim 4.20)
	id 19Ox8E-0001aK-JY
	for qemu-devel@nongnu.org; Sun, 08 Jun 2003 06:10:34 -0400
Received: from free.fr (unknown [81.48.134.159])
	by mwinf0402.wanadoo.fr (SMTP Server) with ESMTP id 762028000E1
	for <qemu-devel@nongnu.org>; Sun,  8 Jun 2003 12:10:31 +0200 (CEST)
Message-ID: <3EE30B8E.5070600@free.fr>
Date: Sun, 08 Jun 2003 12:10:22 +0200
From: Fabrice Bellard <fabrice.bellard@free.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] Sparc port
Reply-To: qemu-devel@nongnu.org
List-Id: <qemu-devel.nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Subscribe: <http://mail.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
List-Archive: <http://mail.gnu.org/pipermail/qemu-devel>
List-Unsubscribe: <http://mail.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
To: qemu-devel@nongnu.org


I am now trying to make the Sparc port work again. I added a sparc 
disassembler so that debugging is easier.

In order to support direct block chaining, it is necessary that no 
prologue or epilogue are added in the generated code. It should be easy 
to do by moving the add/sub sp/fp in the call code in exec-i386.c.

Moreover, the 'restore' used in exec-i386.c in cpu_loop_exit() is not 
safe because we cannot be sure that there was exactly one call level.

I have two ideas :

1) We use -mflat for exec-i386.c and helper-i386.c but not for op-i386.c 
to avoid gcc bugs. Now that op-i386.c only contains opcodes, the code 
inside should almost look like '-mflat' code.

2) We can patch cpu_exit_loop() by doing the right number of restores 
(maybe a single longjmp would suffice as l0...l7 are still saved.


Another more general idea for all archs is to call the generated code 
with a 'jump' instead of doing a call. It would be marginaly more 
complicated and would permit more optimisation (currently, on PowerPC 
and Alpha the code is very inefficient if a helper is called because the 
return address must be saved in a new generated stack frame).

Fabrice.