Re: [Qemu-devel] [PATCH] SH4: convert fmov/fadd to TCG

["Blue Swirl" <blauwirbel@gmail.com>]

On 8/31/08, Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp> wrote:
> Thank your for comments, Blue Swirl!
>  The new patch is shown at the end of this mail.
>  Reviews are welcome, again.
>
>  Blue Swirl wrote:
>
> > > On 8/30/08, Shin-ichiro KAWASAKI <kawasaki@juno.dti.ne.jp> wrote:
> >
> > > >> This patch converts two SH4 float instructions, 'fmov Rm,Rn' and
> > > >>  'fadd' into TCG.  Before converting other float instructions
> > > >>  into TCG, comments on it will be appreciated.
> > > >>
> > > >>  - TCG variables intorudced for float operation : FT[01], and DT[01].
> > > >>  - I think float registers 'fregs' are not to be mapped for
> > > >>   TCG variables, because TCG does not support float operations, now.
> > >
> > >
> > > In TCG README Fabrice mentioned that he's working on a floating point
> > > version. It would be nice to get that committed, already m68k has a
> > > fake version. I did not use TCG variables for float just because I've
> > > been waiting for that. It's not possible to pass env->fp_status
> > > cleanly now (for example to call softfloat functions directly). And
> > > for example on Sparc host, moving data from integer registers to
> > > floating point registers must use memory in between them so there the
> > > integer TCG registers should be separate from float TCG registers.
> >
>
>  I agree that it is important to conisder mapping fregs ot TCG feature
>  like m68k implementation does. But I think this work will take too long
>  time, if I do it, and it will be some break for converting TCG work.
>  I think it is not too late to do this work after eliminating 'op.c'.

That's a valid approach, of course.

>  And I have a question on it.
>  As you pointed out below, two 32 bit registers are concatanated as one
>  64 bit register.  When floating point TCG variables introduced in the
> future,
>  it is straight to map one memory region for 32bit TCG variable and 64bit
>  TCG variable.  I wonder such two way mapping suit for TCG, or not.

I think it depends how well TCG can detect aliased variables. As i386
does not use TCG variables for AL, AX and EAX, I guess that it can't.
This is of course just speculation.

> > > There is no need to pass env as a parameter, it's available to
> > > op_helper.c code anyway.
> >
>
>  Indeed. Thanks!
>
>
> > > I guess that like in Sparc, two 32 bit fregs can be combined to a 64
> > > bit double. Please have a look at target-sparc/translate.c on the use
> > > of CPU_DoubleU, there should be a safer way to access the registers.
> >
>
>  Thanks. I wrote new codes for load/store function, following sparc.

Looks good, except this small thing below:
>  +    printf("initial offset : %d\n", offsetof(CPUState, dt0));