Malc, your sse-movq.patch works for me. Thanks.
> soft-float was a red herring, translate.c is at fault here (interpreter
> does not use it, hence behaved correctly)
>
> translate.c:3009
> if (b1 >= 2 && ((b >= 0x50 && b <= 0x5f) ||
> b == 0xc2)) {
> /* specific case for SS
I found out why cc1 and also GDB had a segfault after I fixed the user
emulator. Branch distances over 1MB were not calculated correctly, shift
operation was done before sign extension. That made the 1MB branches
negative, and probably corrupted 2MB branches.
Now I can compile some programs ei
This patch makes sparc32 user emulator work again.
Programs using vfork still don't work. I'm not sure if the vfork case can be
made to work correctly with qemu blindly using vfork. Can Qemu obey the
vfork use rules (no system calls except exec family or _exit etc.)?
_
Hi,
On 6/20/06, Sylvain Petreolle <[EMAIL PROTECTED]> wrote:
--- Julian Seward <[EMAIL PROTECTED]> a écrit :
> >
> > Running it on a CPU without SSE2, if i'm allowed to venture a gues.
>
> Yup. Try 'strace ./sse2test' and see if it gets SIGILLs thrown at it.
>
> J
>
You are right, I get SIGILL
--- Julian Seward <[EMAIL PROTECTED]> a écrit :
> >
> > Running it on a CPU without SSE2, if i'm allowed to venture a gues.
>
> Yup. Try 'strace ./sse2test' and see if it gets SIGILLs thrown at it.
>
> J
>
You are right, I get SIGILLs.
Seems I was wrong thinking Athlon xp was able to support
On Tue, 20 Jun 2006, Julian Seward wrote:
As for cvttps2dq i ran it with interpreter which uses outdated(i.e. non
soft-float) conversion routines and it passed, so my guess would be that
this is float32_to_int32_round_to_zero vs (int32_t) cast issue.
I had a feeling this is a garbage-in-memory
On Tue, Jun 20 2006, Jens Axboe wrote:
> On Tue, Jun 20 2006, malc wrote:
> > On Tue, 20 Jun 2006, Sylvain Petreolle wrote:
> >
> > >--- Julian Seward <[EMAIL PROTECTED]> a ?crit :
> > >>
> > >>The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
> > >>correctly, as shown by the attache
On Tue, Jun 20 2006, malc wrote:
> On Tue, 20 Jun 2006, Sylvain Petreolle wrote:
>
> >--- Julian Seward <[EMAIL PROTECTED]> a ?crit :
> >>
> >>The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
> >>correctly, as shown by the attached program. It should print
> >>
> >> cvttps2dq_1 ..
> > [EMAIL PROTECTED] qemu]$ gcc -msse2 sse2test.c -o sse2test
> > [EMAIL PROTECTED] qemu]$ ./sse2test
> > cvttps2dq_1 ... failed
> > cvttps2dq_2 ... failed
> > movdq2q_1 ... failed
> > movq2dq_1 ... failed
> >
> > what am i doing wrong here ?
>
> Running it on a CPU without SSE2, if i'm allowed t
On Tue, 20 Jun 2006, Sylvain Petreolle wrote:
--- Julian Seward <[EMAIL PROTECTED]> a ?crit :
The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
correctly, as shown by the attached program. It should print
cvttps2dq_1 ... ok
cvttps2dq_2 ... ok
movdq2q_1 ... ok
movq2dq_1
--- Julian Seward <[EMAIL PROTECTED]> a écrit :
>
> The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
> correctly, as shown by the attached program. It should print
>
> cvttps2dq_1 ... ok
> cvttps2dq_2 ... ok
> movdq2q_1 ... ok
> movq2dq_1 ... ok
>
>
I tried your program
On Tuesday 20 June 2006 12:29, malc wrote:
> The signature of movdq2q is Pq, VRq and for movq2dq - Vo, PRq it appears
> that translate.c gets it backwards, attached patch should deal with it.
Cool.
> As for cvttps2dq i ran it with interpreter which uses outdated(i.e. non
> soft-float) conversion
On Tue, 20 Jun 2006, Julian Seward wrote:
The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
correctly, as shown by the attached program. It should print
cvttps2dq_1 ... ok
cvttps2dq_2 ... ok
movdq2q_1 ... ok
movq2dq_1 ... ok
but instead produces
cvttps2dq_1 ... ok
cvttps
The SSE2 instructions cvttps2dq, movdq2q, movq2dq do not behave
correctly, as shown by the attached program. It should print
cvttps2dq_1 ... ok
cvttps2dq_2 ... ok
movdq2q_1 ... ok
movq2dq_1 ... ok
but instead produces
cvttps2dq_1 ... ok
cvttps2dq_2 ... not ok
result0.sd[0] = 12
Fabrice Bellard wrote:
Another point is that doing:
+target_long args[6];
+
+tputl(args, arg1);
+tputl(args+1, arg2);
+tputl(args+2, arg3);
+tputl(args+3, arg4);
+tputl(args+4, arg5);
+tputl(args+5, arg6);
at the start of every syscall is not acceptable. You should a
Raphaël Rigo wrote:
> Fabrice Bellard wrote:
> > Hi,
> >
> > Is it really needed to duplicate socket.h ? What are the differences for
> > mips ?
> >
> > Regards,
> >
> > Fabrice.
> >
> Hi,
> almost all socket related constants are different on MIPS. I thought it would
> be
> cleaner to define
16 matches
Mail list logo