[Qemu-devel] Status of the SH4 / ARM7 emulators

[Qemu-devel] Status of the SH4 / ARM7 emulators

[Renato Utsch]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

Hello people, I am new to this mailing list, so if I do something wrong say
to me...

Well, I am making a dreamcast emulator and I wanted to know the status of
the sh-4 emulator, if it is stable, if it actually works, etc... And the
same for the ARM7-TDMI emulator (if QEMU supports it, it supports?),
because this would save months of work. QEMU sh-4 and arm emulators are
stable enough for doing something like that?

I will look the documentation, but how could I use the QEMU emulation
without opening the actual program? I mean, there is a library for using
the emulation in another programs?


Thanks!

Renato

[-- Attachment #2: Type: text/html, Size: 731 bytes --]

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Peter Maydell]

On 19 November 2011 21:20, Renato Utsch <renatoutsch@gmail.com> wrote:
> Well, I am making a dreamcast emulator and I wanted to know the status of
> the sh-4 emulator, if it is stable, if it actually works, etc... And the
> same for the ARM7-TDMI emulator (if QEMU supports it, it supports?), because
> this would save months of work.

The ARM target doesn't implement ARM7TDMI. The oldest CPU we support
is the ARM9. (I suppose ARM7TDMI could in theory be added; we have
other v4T architecture cores already. Personally I'm more interested
in the newer end of ARM's product line than the older end, though...)

> I will look the documentation, but how could I use the QEMU emulation
> without opening the actual program? I mean, there is a library for using the
> emulation in another programs?

QEMU doesn't support this -- it emulates an entire system, it does not
provide a pluggable component you can use to do only "cpu emulation"
as part of some other system emulator.

We also don't support having multiple CPUs with different architectures
in one emulator: you can have an ARM emulator, or an SH4 emulator,
but not an emulation of a system with both an ARM and an SH4 core.

-- PMM

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Andreas Färber]

Am 19.11.2011 22:53, schrieb Peter Maydell:
> We also don't support having multiple CPUs with different architectures
> in one emulator: you can have an ARM emulator, or an SH4 emulator,
> but not an emulation of a system with both an ARM and an SH4 core.

Although I have recently been investigating exactly that combo.

* Part of the problem is that common CPUState fields are not at the
start of the struct. I have therefore been playing with a
CPU_COMMON_PREFIX at the start of the struct and using a macro for
clearing on reset, which preserves part of the common prefix fields.
* Given a CPUState*, we need a way to differentiate different CPU types.
I used an enum CPUType cpu_type as first field in CPU_COMMON_PREFIX.
* cpu_mmu_index() is static inline, we should #define it to a non-static
function in helper.c.
* How to get declarations for such target-specific functions when
#include "target-xyz/cpu.h" would overwrite cpu_init, TARGET_PAGE_SIZE
and other defines?

I hope this'll get easier with QOM.

Andreas

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Peter Maydell]

On 20 November 2011 20:51, Andreas Färber <andreas.faerber@web.de> wrote:
> Am 19.11.2011 22:53, schrieb Peter Maydell:
>> We also don't support having multiple CPUs with different architectures
> Although I have recently been investigating exactly that combo.

Yes, it would be nice to be able to do it cleanly...

> * Part of the problem is that common CPUState fields are not at the
> start of the struct. I have therefore been playing with a
> CPU_COMMON_PREFIX at the start of the struct and using a macro for
> clearing on reset, which preserves part of the common prefix fields.

I've never much liked the way we clear the common fields in
CPUState anyway -- having every target-foo know that the first
not-to-be-cleared field in CPU_COMMON is called "breakpoints" is
pretty ugly...

> * Given a CPUState*, we need a way to differentiate different CPU types.
> I used an enum CPUType cpu_type as first field in CPU_COMMON_PREFIX.
> * cpu_mmu_index() is static inline, we should #define it to a non-static
> function in helper.c.
> * How to get declarations for such target-specific functions when
> #include "target-xyz/cpu.h" would overwrite cpu_init, TARGET_PAGE_SIZE
> and other defines?
>
> I hope this'll get easier with QOM.

It seems to me that ideally a CPU should be just another device
except with an extended interface that implements "this is a
device which can run code and has to be scheduled". Ideally the
common code shouldn't need to know what CPU type a schedulable
object actually is. (I wonder if you could have a "some CPUs
are KVM and some are TCG" config...?)

(How we get there from here is a different question, of course;
QOM ought to let you define an appropriate interface for the
"provide the hooks for being a schedulable object" if we've
got the QOM design right, though.)

-- PMM

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Richard Henderson]

On 11/20/2011 12:51 PM, Andreas Färber wrote:
> * Part of the problem is that common CPUState fields are not at the
> start of the struct. I have therefore been playing with a
> CPU_COMMON_PREFIX at the start of the struct and using a macro for
> clearing on reset, which preserves part of the common prefix fields.

Most of the RISC hosts have a limited displacement in their load and
store instructions.  E.g. 14 bits for Sparc, 12 bits for ARM, 10.
We want to be able to load and store the target cpu registers very
efficiently.

If you move all the common fields to the beginning, that will include
the (rather large) TLB tables, and overflow those small offsets.

This change would almost certainly be a Large Mistake.


r~

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Andreas Färber]

Am 23.11.2011 22:59, schrieb Richard Henderson:
> On 11/20/2011 12:51 PM, Andreas Färber wrote:
>> * Part of the problem is that common CPUState fields are not at the
>> start of the struct. I have therefore been playing with a
>> CPU_COMMON_PREFIX at the start of the struct and using a macro for
>> clearing on reset, which preserves part of the common prefix fields.
> 
> Most of the RISC hosts have a limited displacement in their load and
> store instructions.  E.g. 14 bits for Sparc, 12 bits for ARM, 10.
> We want to be able to load and store the target cpu registers very
> efficiently.
> 
> If you move all the common fields to the beginning, that will include
> the (rather large) TLB tables, and overflow those small offsets.
> 
> This change would almost certainly be a Large Mistake.

Then what is your suggestion?

Today, common code is accessing env-> struct members directly for
icount, TLB, etc. If they're at the end of the struct, offsets vary and
we can't cast to a common-subset struct.

Anthony's qom-upstream.4 branch doesn't seem to touch CPUState yet.
Having an empty C++ base class with virtual, non-implemented accessor
methods that are implemented for each arch is the only solution I can
think of other than "proxy" functions with large switches based on a
common (=prefixed) type field.

Andreas

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Tristan Gingold]

On Nov 24, 2011, at 11:44 AM, Andreas Färber wrote:

> Am 23.11.2011 22:59, schrieb Richard Henderson:
>> On 11/20/2011 12:51 PM, Andreas Färber wrote:
>>> * Part of the problem is that common CPUState fields are not at the
>>> start of the struct. I have therefore been playing with a
>>> CPU_COMMON_PREFIX at the start of the struct and using a macro for
>>> clearing on reset, which preserves part of the common prefix fields.
>> 
>> Most of the RISC hosts have a limited displacement in their load and
>> store instructions.  E.g. 14 bits for Sparc, 12 bits for ARM, 10.
>> We want to be able to load and store the target cpu registers very
>> efficiently.
>> 
>> If you move all the common fields to the beginning, that will include
>> the (rather large) TLB tables, and overflow those small offsets.
>> 
>> This change would almost certainly be a Large Mistake.
> 
> Then what is your suggestion?

Point to the middle ?

IE, positive offsets for the common structure, negative offsets for the architecture defined ones.

> 
> Today, common code is accessing env-> struct members directly for
> icount, TLB, etc. If they're at the end of the struct, offsets vary and
> we can't cast to a common-subset struct.
> 
> Anthony's qom-upstream.4 branch doesn't seem to touch CPUState yet.
> Having an empty C++ base class with virtual, non-implemented accessor
> methods that are implemented for each arch is the only solution I can
> think of other than "proxy" functions with large switches based on a
> common (=prefixed) type field.
> 
> Andreas
> 

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Richard Henderson]

On 11/29/2011 01:09 AM, Tristan Gingold wrote:
>> Then what is your suggestion?
> 
> Point to the middle ?
> 
> IE, positive offsets for the common structure, negative offsets for the architecture defined ones.

Well, Andreas wants to put the common data at the beginning, which would
mean vice versa -- negative for common and positive for arch.

Which sounds like it would actually work out well, since ARM only has
small positive offsets for address formation.


r~

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Andreas Färber]

Hello Renato,

Am 19.11.2011 22:20, schrieb Renato Utsch:
> I am making a dreamcast emulator and I wanted to know the status
> of the sh-4 emulator, if it is stable, if it actually works, etc... And
> the same for the ARM7-TDMI emulator (if QEMU supports it, it supports?),
> because this would save months of work. QEMU sh-4 and arm emulators are
> stable enough for doing something like that?

I know little about Dreamcast, but from looking at Wikipedia [1] it
looks as if ARM7 is used only for sound. So unless you want to develop a
new sound firmware, you can treat it as a black box and focus on SH-4.

sh4-softmmu has been successfully used to boot Linux on certain boards.
What will remain is for you to add a Dreamcast machine, instantiating
the CPU and devices, and implementing those not available in QEMU today,
such as GD-ROM. For PowerVR CLX2 you might be able to share some code
with OMAP's PowerVR SGX.

> how could I use the QEMU emulation
> without opening the actual program? I mean, there is a library for using
> the emulation in another programs?

No. The way to go about your project would be to add the missing pieces
to QEMU's system emulation, mostly in hw/ directory, and to run it via
qemu-system-sh4 -M dreamcast.

You should work with Git and submit any target-sh4 fixes to this mailing
list as well as probably any new devices.
If however you intend to do any Dreamcast-specific frontend skinning,
such parts would probably be less interesting for qemu.git.

You might want to compare ZX Spectrum emulation [2], the Android SDK [3]
and iEmu [4].

Regards,

Andreas

[1] http://en.wikipedia.org/wiki/Dreamcast#Hardware
[2] http://wiki.qemu.org/Features/Z80
[3] http://tools.android.com/overview
[4] http://www.iemu.org/

Re: [Qemu-devel] Status of the SH4 / ARM7 emulators

[Peter Maydell]

On 20 November 2011 18:08, Andreas Färber <andreas.faerber@web.de> wrote:
> sh4-softmmu has been successfully used to boot Linux on certain boards.
> What will remain is for you to add a Dreamcast machine, instantiating
> the CPU and devices, and implementing those not available in QEMU today,
> such as GD-ROM.

How good is QEMU likely to be at console emulation? The general
impression I've got is that console emulators have to be quite
picky about timing and generally aim much closer to the 'cycle
accurate' end of the spectrum if they want to have a chance of
running games correctly.

> For PowerVR CLX2 you might be able to share some code
> with OMAP's PowerVR SGX.

We don't currently model the SGX in the OMAP QEMU models, by the way.

-- PMM