From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1L1pEj-0003Pg-MH for qemu-devel@nongnu.org; Sun, 16 Nov 2008 16:32:53 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1L1pEi-0003PA-3j for qemu-devel@nongnu.org; Sun, 16 Nov 2008 16:32:53 -0500 Received: from [199.232.76.173] (port=43020 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1L1pEh-0003P3-Vq for qemu-devel@nongnu.org; Sun, 16 Nov 2008 16:32:52 -0500 Received: from mailout02.t-online.de ([194.25.134.17]:39588) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1L1pEh-0006HZ-HX for qemu-devel@nongnu.org; Sun, 16 Nov 2008 16:32:51 -0500 Date: Sun, 16 Nov 2008 22:34:32 +0100 From: Simon Willcocks Subject: Re: [Qemu-devel] [PATCH] ARM CPSR and conditional instructions - revisited Message-ID: References: <6a7a0afe4f.simonwillcocks@home.invalid> <200811141248.31086.paul@codesourcery.com> <200811161649.17521.paul@codesourcery.com> In-Reply-To: <200811161649.17521.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Paul Brook In message <200811161649.17521.paul@codesourcery.com> you wrote: > > 2. How do I compile my simple test program? > > > > This used to be good enough: > > > > gcc flags_test1.c -o flags_test1 qemu-0.9.1/arm-linux-user/libqemu.a \ > > -I qemu-0.9.1 -DNEED_CPU_H -Iqemu-0.9.1/fpu -I > > qemu-0.9.1/arm-linux-user/ \ -Wall qemu-0.9.1/osdep.c -I > > qemu-0.9.1/target-arm/ -D_XOPEN_SOURCE=600 > > > > But now libqemu.a seems to need a lot of features from other places that I > > can't easily identify. > > Don't do that. libqemu has never really been usable as a standaline library. Unfortunately, that's exactly how I want to use it! What I have is a system, based on a Linux kernel, that behaves similarly to RISC OS; the OS developed by Acorn to run on their Acorn RISC Machine processors, later spun off to be Advanced RISC Machines Ltd.. I have tried to make it sufficiently similar that it should be relatively easy to map RISC OS system calls (especially the WIMP and font ones) to the ROLF interface, so that RISC OS programs can be ported to run on faster hardware. There's a new interface to the Wimp, which adds a couple of features so that people can make use of pre-emptive scheduling and asynchronous I/O from Linux but, at heart, is the cooperative mechanism from 1987 that still works very well indeed but is limited by the speed of ARM processors. One feature that I would like to implement is the ability to run some RISC OS programs under ROLF (on i386), for which I need an emulator. The example I chose to start with was a vector graphics renderer for a program called ArtWorks, which requires some "Relocatable Modules" which have been supported over the last sixeen years on RISC OS. (A Relocatable Module can be any combination of a shared library, a device driver, a kernel extension module, or an application.) I don't need to emulate the hardware of a RISC OS computer (nor would I want to; Acorn wrote operating systems with a good abstraction from the hardware from before MS were around, and programs generally used it). What I do need to do is convince old software that it is running on an ARM processor (that's where QEMU comes in) and interfacing with RISC OS when it makes a SWI call. To do the latter, I'm implementing a shared library that can provide a one-routine interface to run any* RISC OS system call, and trying to make those calls available to ARM code in an emulator as a way to get native RISC OS applications to run. The same library is callable from BASIC (built in to RISC OS and therefore commonly used for application development) via the Brandy basic interpreter. As at qemu-0.9.1, that seemed to be relatively easy, now it seems to be harder, and I'm not sure why. I could be wrong, but I think there is a movement from emulation of a particular processor to emulation of a particular processor running a particular OS, on a particular piece of hardware, which is probably very useful for many people, but isn't so much for me. I'd like the abstraction to allow me to extract the processor without any preconceptions; to be able to use QEMU as a tool, rather than being forced to integrate ROLF into QEMU. * potentially; many won't ever be needed. -- ROLF - The RISC OS Look and Feel on Linux. http://stoppers.drobe.co.uk http://ro-lookandfeel.blogspot.com/