Re: [Qemu-devel] [PATCH] ARM CPSR and conditional instructions - revisited

[Simon Willcocks <simon.willcocks@t-online.de>]

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/