qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
* [Qemu-devel] ColdFire/m68k target
@ 2006-10-22  0:44 Paul Brook
  2006-10-31 20:20 ` Neo Jia
  0 siblings, 1 reply; 3+ messages in thread
From: Paul Brook @ 2006-10-22  0:44 UTC (permalink / raw)
  To: qemu-devel

I've just committed ColdFire/M68K target support to cvs. This implements 
usermode emulation for ColdFire CPUs, including the FPU. The CPU emulation 
has been reasonably well tested, but linux syscall emulation only lightly 
tested.

For those that don't know, ColdFire is a subset of the old m68k architecture, 
with a few minor differences, and a slightly different FPU.

I'll probably be implementing full system emulation sometime (Freescale 
M5xxxEVB dev board).

M68k code will not run on the current emulation. Implementing the missing 68k 
bits (addressing modes and bitfield instructions) probably wouldn't be that 
hard. Implementing 68881 FPU emulation is a bit harder 'cos it 
uses "extended" precision registers.

The code is a bit different to most other qemu targets because I originally 
wrote it for my code generation backend rather than dyngen. The main 
translation code is unmodified, with glue to make it work with dyngen. For 
this reason the generated code isn't as efficient as it could be. 

Paul

P.S.
Anyone wanting to play with ColdFire emulation can find toolchains at
http://www.codesourcery.com/gnu_toolchains/coldfire/index_html

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] ColdFire/m68k target
  2006-10-22  0:44 [Qemu-devel] ColdFire/m68k target Paul Brook
@ 2006-10-31 20:20 ` Neo Jia
  2006-10-31 20:32   ` Paul Brook
  0 siblings, 1 reply; 3+ messages in thread
From: Neo Jia @ 2006-10-31 20:20 UTC (permalink / raw)
  To: paul; +Cc: qemu-devel

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

Paul,

I just checkout from CVS repository and encountered the following problem
while building the code.

It seems you eleminate your original arguments of function gen_op_divs and
gen_op_divu.

Could you take a look?

gcc -Wall -O2 -g -fno-strict-aliasing -I. -I..
-I/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k
-I/home/cjia/research/Operating_Systems/qemu_cvs
-I/home/cjia/research/Operating_Systems/qemu_cvs/linux-user
-I/home/cjia/research/Operating_Systems/qemu_cvs/linux-user/m68k
-D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
-I/home/cjia/research/Operating_Systems/qemu_cvs/fpu
-I/home/cjia/research/Operating_Systems/qemu_cvs/slirp -c -o
translate.o/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k/translate.c
/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k/translate.c: In
function `disas_divw':
/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k/translate.c:717:
error: too many arguments to function `gen_op_divs'
/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k/translate.c:719:
error: too many arguments to function `gen_op_divu'
/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k/translate.c: In
function `disas_divl':
/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k/translate.c:750:
error: too many arguments to function `gen_op_divs'
/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k/translate.c:752:
error: too many arguments to function `gen_op_divu'
make[1]: *** [translate.o] Error 1
make[1]: Leaving directory
`/home/cjia/research/Operating_Systems/qemu_cvs/m68k-user'
make: *** [subdir-m68k-user] Error 2

Thanks,
Neo

On 10/21/06, Paul Brook <paul@codesourcery.com> wrote:
>
> I've just committed ColdFire/M68K target support to cvs. This implements
> usermode emulation for ColdFire CPUs, including the FPU. The CPU emulation
> has been reasonably well tested, but linux syscall emulation only lightly
> tested.
>
> For those that don't know, ColdFire is a subset of the old m68k
> architecture,
> with a few minor differences, and a slightly different FPU.
>
> I'll probably be implementing full system emulation sometime (Freescale
> M5xxxEVB dev board).
>
> M68k code will not run on the current emulation. Implementing the missing
> 68k
> bits (addressing modes and bitfield instructions) probably wouldn't be
> that
> hard. Implementing 68881 FPU emulation is a bit harder 'cos it
> uses "extended" precision registers.
>
> The code is a bit different to most other qemu targets because I
> originally
> wrote it for my code generation backend rather than dyngen. The main
> translation code is unmodified, with glue to make it work with dyngen. For
> this reason the generated code isn't as efficient as it could be.
>
> Paul
>
> P.S.
> Anyone wanting to play with ColdFire emulation can find toolchains at
> http://www.codesourcery.com/gnu_toolchains/coldfire/index_html
>
>
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>



-- 
I would remember that if researchers were not ambitious
probably today we haven't the technology we are using!

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [Qemu-devel] ColdFire/m68k target
  2006-10-31 20:20 ` Neo Jia
@ 2006-10-31 20:32   ` Paul Brook
  0 siblings, 0 replies; 3+ messages in thread
From: Paul Brook @ 2006-10-31 20:32 UTC (permalink / raw)
  To: qemu-devel

On Tuesday 31 October 2006 20:20, Neo Jia wrote:
> Paul,
>
> I just checkout from CVS repository and encountered the following problem
> while building the code.
>
> It seems you eleminate your original arguments of function gen_op_divs and
> gen_op_divu.
>
> Could you take a look?
>
> gcc -Wall -O2 -g -fno-strict-aliasing -I. -I..
> -I/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k
> -I/home/cjia/research/Operating_Systems/qemu_cvs
> -I/home/cjia/research/Operating_Systems/qemu_cvs/linux-user
> -I/home/cjia/research/Operating_Systems/qemu_cvs/linux-user/m68k
> -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE
> -I/home/cjia/research/Operating_Systems/qemu_cvs/fpu
> -I/home/cjia/research/Operating_Systems/qemu_cvs/slirp -c -o
> translate.o/home/cjia/research/Operating_Systems/qemu_cvs/target-m68k/trans
>late.c
> /home/cjia/research/Operating_Systems/qemu_cvs/target-m68k/translate.c: In
> function `disas_divw':

Ah, this is a dyngen bug. op_divw contains "if (PARAM1) {...}". PARAM1 is 
implemented by taking the address of a symbol. gcc knows that symbols can 
never have address zero (because the C standard says so), and eliminates the 
whole block of code.

The patch below fixes it (weak symbols can be zero).  However it break lame 
hosts that don't support weak symbols, eg. win32. I'm still trying to figure 
out a proper solution.

Index: dyngen-exec.h
===================================================================
RCS file: /sources/qemu/qemu/dyngen-exec.h,v
retrieving revision 1.29
diff -u -p -r1.29 dyngen-exec.h
--- dyngen-exec.h	18 Jul 2006 21:23:34 -0000	1.29
+++ dyngen-exec.h	31 Oct 2006 16:53:38 -0000
@@ -222,7 +222,7 @@ extern int __op_param3 __hidden;
 #if defined(__APPLE__)
 static int __op_param1, __op_param2, __op_param3;
 #else
-extern int __op_param1, __op_param2, __op_param3;
+extern int __attribute__((weak)) __op_param1, __op_param2, __op_param3;
 #endif
 #define PARAM1 ((long)(&__op_param1))
 #define PARAM2 ((long)(&__op_param2))

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2006-10-31 20:32 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-10-22  0:44 [Qemu-devel] ColdFire/m68k target Paul Brook
2006-10-31 20:20 ` Neo Jia
2006-10-31 20:32   ` Paul Brook

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).