* [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).