[Qemu-devel] sparc smul problem

[Qemu-devel] sparc smul problem

[Vince Weaver]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 937 bytes --]

Hello!

I've been stuck on this all weekend, as I can't find where the actual 
problem is. I might be completely missing it, but I've tried a lot of 
things and can't make it work.

On SPARC, the "smul" instruction multiplies two numbers, puts the result 
in the result register but also puts the top 32-bits of the 64-bit result 
into the "Y" register.

As the attached code shows, the value of "Y" is wrong.  Somehow after the 
multiply, the top 32 bits of the product rae all zeros.  I've played 
around with the code generated by translate.c, and it looks like the shift 
and other instructions all work properly, but the 64-bit multiply the 
result is somehow being truncated.  But I've looked at the generated code 
(on x86_64) and it looks like it is doing the right thing.

So anyway, I'll have to take a look at this again later, but in case 
anyone else wants to look at it in case I am missing anything obvious.

Thanks

Vince

[-- Attachment #2: Type: TEXT/PLAIN, Size: 1843 bytes --]

! as -o smul.o smul.s ; ld -o smul smul.o

.equ SYSCALL_EXIT,1	
.equ SYSCALL_WRITE,4
.equ STDOUT,1

	.globl _start
_start:	

	set	0xc22e4507,%g1
	set	0x386d4380,%g4
before:	
	smul	%g4,%g1,%g2
	rd	%y,%g3
stop:	
! g2 should be (f25fbc80) 1f2e5880
! g3 should be (00000000) f25fbc80

        set    0x1f2e5880,%g5
     	cmp    %g2,%g5
	bne    wrong_lower
	nop
	
	set	correct_answer,%o1
	ba	print_lower
	nop
	
wrong_lower:
	set 	wrong_answer,%o1


print_lower:
	call	write_stdout
	nop

! Check to see if Y was correct

        set    0xf25fbc80,%g5
     	cmp    %g3,%g5
	bne    print_wrong_y
	nop
	
	set	correct_y,%o1
	ba	print_y
	nop
	
print_wrong_y:
	set 	wrong_y,%o1


print_y:
	call	write_stdout
	nop


	
	!================================
	! Exit
	!================================
exit:		
        mov	0,%o0			! exit value
        mov	SYSCALL_EXIT,%g1        ! put the exit syscall number in g1
        ta      0x10			! and exit


	#================================
	# WRITE_STDOUT
	#================================
	# %o1 has string

write_stdout:

	set	SYSCALL_WRITE,%g1	! Write syscall in %g1
	set	STDOUT,%o0		! 1 in %o0 (stdout)
	set	0,%o2			! 0 (count) in %o2

str_loop1:
	ldub	[%o1+%o2],%l1		! load byte
	cmp	%l1,%g0			! compare against zero
	bnz	str_loop1		! if not nul, repeat
	# BRANCH DELAY SLOT
	inc	%o2			! increment count

	dec	%o2			! correct count	
	ta	0x10			! run the syscall

	retl
	nop




!===========================================================================
.data
!===========================================================================

data_region:		
wrong_answer:	.ascii "Wrong answer\n\0"
wrong_y:        .ascii "Wrong Y\n\0"
correct_answer:	.ascii "Correct answer\n\0"
correct_y:	.ascii "Correct Y\n\0"

[-- Attachment #3: Type: APPLICATION/octet-stream, Size: 1226 bytes --]

Re: [Qemu-devel] sparc smul problem

[Blue Swirl]

On 9/1/08, Vince Weaver <vince@csl.cornell.edu> wrote:
> Hello!
>
>  I've been stuck on this all weekend, as I can't find where the actual
> problem is. I might be completely missing it, but I've tried a lot of things
> and can't make it work.
>
>  On SPARC, the "smul" instruction multiplies two numbers, puts the result in
> the result register but also puts the top 32-bits of the 64-bit result into
> the "Y" register.
>
>  As the attached code shows, the value of "Y" is wrong.  Somehow after the
> multiply, the top 32 bits of the product rae all zeros.  I've played around
> with the code generated by translate.c, and it looks like the shift and
> other instructions all work properly, but the 64-bit multiply the result is
> somehow being truncated.  But I've looked at the generated code (on x86_64)
> and it looks like it is doing the right thing.
>
>  So anyway, I'll have to take a look at this again later, but in case anyone
> else wants to look at it in case I am missing anything obvious.

At least the store and load do not match:
 ---- 0x10084
 mov_i64 tmp16,g1
 mov_i64 tmp17,g4
 mul_i64 tmp17,tmp16,tmp17
 movi_i64 tmp18,$0x20
 shr_i64 tmp16,tmp17,tmp18
 st_i32 tmp16,env,$0x58
^^^^^
 mov_i64 loc3,tmp17
 mov_i64 g2,loc3

 ---- 0x10088
 ld_i64 tmp0,env,$0x58
^^^^^
mov_i64 g3,tmp0

Re: [Qemu-devel] sparc smul problem

[Blue Swirl]

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

On 9/1/08, Vince Weaver <vince@csl.cornell.edu> wrote:
> Hello!
>
>  I've been stuck on this all weekend, as I can't find where the actual
> problem is. I might be completely missing it, but I've tried a lot of things
> and can't make it work.
>
>  On SPARC, the "smul" instruction multiplies two numbers, puts the result in
> the result register but also puts the top 32-bits of the 64-bit result into
> the "Y" register.
>
>  As the attached code shows, the value of "Y" is wrong.  Somehow after the
> multiply, the top 32 bits of the product rae all zeros.  I've played around
> with the code generated by translate.c, and it looks like the shift and
> other instructions all work properly, but the 64-bit multiply the result is
> somehow being truncated.  But I've looked at the generated code (on x86_64)
> and it looks like it is doing the right thing.
>
>  So anyway, I'll have to take a look at this again later, but in case anyone
> else wants to look at it in case I am missing anything obvious.

Y loads and stores were not correct, the attached patch fixes the
problem. I'm still running some tests.

[-- Attachment #2: fix_smul.diff --]
[-- Type: plain/text, Size: 2699 bytes --]

Re: [Qemu-devel] sparc smul problem

[Blue Swirl]

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

On 9/1/08, Vince Weaver <vince@csl.cornell.edu> wrote:
> Hello!
>
>  I've been stuck on this all weekend, as I can't find where the actual
> problem is. I might be completely missing it, but I've tried a lot of things
> and can't make it work.
>
>  On SPARC, the "smul" instruction multiplies two numbers, puts the result in
> the result register but also puts the top 32-bits of the 64-bit result into
> the "Y" register.
>
>  As the attached code shows, the value of "Y" is wrong.  Somehow after the
> multiply, the top 32 bits of the product rae all zeros.  I've played around
> with the code generated by translate.c, and it looks like the shift and
> other instructions all work properly, but the 64-bit multiply the result is
> somehow being truncated.  But I've looked at the generated code (on x86_64)
> and it looks like it is doing the right thing.
>
>  So anyway, I'll have to take a look at this again later, but in case anyone
> else wants to look at it in case I am missing anything obvious.

It looks like TCG on i386 host generates incorrect code for mulu2_i32,
I think the op should be imul (unsigned) instead of mul. This patch
fixes the problem.

[-- Attachment #2: fix_tcg_i386_mulu2.diff --]
[-- Type: plain/text, Size: 498 bytes --]

Re: [Qemu-devel] sparc smul problem

[Aurelien Jarno]

On Mon, Sep 01, 2008 at 10:05:45PM +0300, Blue Swirl wrote:
> On 9/1/08, Vince Weaver <vince@csl.cornell.edu> wrote:
> > Hello!
> >
> >  I've been stuck on this all weekend, as I can't find where the actual
> > problem is. I might be completely missing it, but I've tried a lot of things
> > and can't make it work.
> >
> >  On SPARC, the "smul" instruction multiplies two numbers, puts the result in
> > the result register but also puts the top 32-bits of the 64-bit result into
> > the "Y" register.
> >
> >  As the attached code shows, the value of "Y" is wrong.  Somehow after the
> > multiply, the top 32 bits of the product rae all zeros.  I've played around
> > with the code generated by translate.c, and it looks like the shift and
> > other instructions all work properly, but the 64-bit multiply the result is
> > somehow being truncated.  But I've looked at the generated code (on x86_64)
> > and it looks like it is doing the right thing.
> >
> >  So anyway, I'll have to take a look at this again later, but in case anyone
> > else wants to look at it in case I am missing anything obvious.
> 
> It looks like TCG on i386 host generates incorrect code for mulu2_i32,
> I think the op should be imul (unsigned) instead of mul. This patch
> fixes the problem.

According to the IA-32 manual, mul (F7/4) corresponds to unsigned
multiplication, while imul (F7/5) corresponds to signed multiplication.
Therefore the patch does not looks correct.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net

Re: [Qemu-devel] sparc smul problem

[Blue Swirl]

On 9/1/08, Blue Swirl <blauwirbel@gmail.com> wrote:
> On 9/1/08, Vince Weaver <vince@csl.cornell.edu> wrote:
>
> > Hello!
>  >
>  >  I've been stuck on this all weekend, as I can't find where the actual
>  > problem is. I might be completely missing it, but I've tried a lot of things
>  > and can't make it work.
>  >
>  >  On SPARC, the "smul" instruction multiplies two numbers, puts the result in
>  > the result register but also puts the top 32-bits of the 64-bit result into
>  > the "Y" register.
>  >
>  >  As the attached code shows, the value of "Y" is wrong.  Somehow after the
>  > multiply, the top 32 bits of the product rae all zeros.  I've played around
>  > with the code generated by translate.c, and it looks like the shift and
>  > other instructions all work properly, but the 64-bit multiply the result is
>  > somehow being truncated.  But I've looked at the generated code (on x86_64)
>  > and it looks like it is doing the right thing.
>  >
>  >  So anyway, I'll have to take a look at this again later, but in case anyone
>  > else wants to look at it in case I am missing anything obvious.
>
>
> It looks like TCG on i386 host generates incorrect code for mulu2_i32,
>  I think the op should be imul (unsigned) instead of mul. This patch
>  fixes the problem.

Never mind, I read the manuals wrong and the bug was elsewhere.