[Qemu-devel] Re: Some patches for qemu on sparc

[Qemu-devel] Re: Some patches for qemu on sparc

[Jurij Smakov]

On Wed, 8 Feb 2006, Blue Swirl wrote:

> Hi,
>
> The last problem means that gcc decided to make a leaf function, where 
> save/restore is not needed. The register use is not standard, but that 
> shouldn't matter, because the op functions do not take arguments or return a 
> value.
>
> Standard code, parsed by dyngen:
> save
> do stuff
> ret
> restore
>
> leaf code:
> do stuff
> retl
> nop
>
> The solution should be to add code to dyngen.c to detect leaf functions which 
> suppresses the save/restore checks.

Thanks for your feedback. I've added additional check to dyngen.c, which 
checks that function has either save; in the beginning and ret; restore;
in the end, or ends in retl; nop;. That allowed me to get past the arm 
target build failure. Now it fails (during dyngen check) on ppc target, 
the culprit is the following function:

000033d8 <op_stfs_raw>:
     33d8:       9c 03 bf 90     add  %sp, -112, %sp
     33dc:       d1 19 a0 f8     ldd  [ %g6 + 0xf8 ], %f8
     33e0:       91 a0 18 c8     fdtos  %f8, %f8
     33e4:       d1 23 a0 64     st  %f8, [ %sp + 0x64 ]
     33e8:       c8 03 a0 64     ld  [ %sp + 0x64 ], %g4
     33ec:       99 39 20 18     sra  %g4, 0x18, %o4
     33f0:       97 39 20 10     sra  %g4, 0x10, %o3
     33f4:       95 39 20 08     sra  %g4, 8, %o2
     33f8:       c8 28 60 03     stb  %g4, [ %g1 + 3 ]
     33fc:       d8 28 40 00     stb  %o4, [ %g1 ]
     3400:       d6 28 60 01     stb  %o3, [ %g1 + 1 ]
     3404:       d4 28 60 02     stb  %o2, [ %g1 + 2 ]
     3408:       81 c3 e0 08     retl
     340c:       9c 23 bf 90     sub  %sp, -112, %sp

What should dyngen do about a function like that?

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Re: [Qemu-devel] Re: Some patches for qemu on sparc

[Paul Brook]

> Thanks for your feedback. I've added additional check to dyngen.c, which
> checks that function has either save; in the beginning and ret; restore;
> in the end, or ends in retl; nop;. That allowed me to get past the arm
> target build failure. Now it fails (during dyngen check) on ppc target,
> the culprit is the following function:
>
> 000033d8 <op_stfs_raw>:
>      33d8:       9c 03 bf 90     add  %sp, -112, %sp
>      33dc:       d1 19 a0 f8     ldd  [ %g6 + 0xf8 ], %f8
>      33e0:       91 a0 18 c8     fdtos  %f8, %f8
>      33e4:       d1 23 a0 64     st  %f8, [ %sp + 0x64 ]
>      33e8:       c8 03 a0 64     ld  [ %sp + 0x64 ], %g4
>      33ec:       99 39 20 18     sra  %g4, 0x18, %o4
>      33f0:       97 39 20 10     sra  %g4, 0x10, %o3
>      33f4:       95 39 20 08     sra  %g4, 8, %o2
>      33f8:       c8 28 60 03     stb  %g4, [ %g1 + 3 ]
>      33fc:       d8 28 40 00     stb  %o4, [ %g1 ]
>      3400:       d6 28 60 01     stb  %o3, [ %g1 + 1 ]
>      3404:       d4 28 60 02     stb  %o2, [ %g1 + 2 ]
>      3408:       81 c3 e0 08     retl
>      340c:       9c 23 bf 90     sub  %sp, -112, %sp
>
> What should dyngen do about a function like that?

Maybe a better strategy is to force generation of a register window save with 
the FORCE_RET macro.

#define FORCE_RET() asm volatile("":::"o0");

Seems to do the trick.

Paul

Re: [Qemu-devel] Re: Some patches for qemu on sparc

[Jurij Smakov]

On Sat, 11 Feb 2006, Paul Brook wrote:

> Maybe a better strategy is to force generation of a register window save with
> the FORCE_RET macro.
>
> #define FORCE_RET() asm volatile("":::"o0");
>
> Seems to do the trick.
>
> Paul

Hi Paul,

This change does not have any effect on build failure in ppc target. This 
is not surprising, because AFAICT the FORCE_RET macro is only used in arm, 
i386 and sparc targets. Any other ideas?

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

Re: [Qemu-devel] Re: Some patches for qemu on sparc

[Paul Brook]

On Saturday 11 February 2006 05:17, Jurij Smakov wrote:
> On Sat, 11 Feb 2006, Paul Brook wrote:
> > Maybe a better strategy is to force generation of a register window save
> > with the FORCE_RET macro.
> >
> > #define FORCE_RET() asm volatile("":::"o0");
> >
> > Seems to do the trick.
>
> This change does not have any effect on build failure in ppc target. This
> is not surprising, because AFAICT the FORCE_RET macro is only used in arm,
> i386 and sparc targets. Any other ideas?

Fix PPC so it uses FORCE_RET. PPC currently uses it's own RETURN() macro.
I see no good reason for it being different.

Paul

[Qemu-devel] Re: Some patches for qemu on sparc

[Blue Swirl]

>Thanks for your feedback. I've added additional check to dyngen.c, which 
>checks that function has either save; in the beginning and ret; restore;
>in the end, or ends in retl; nop;. That allowed me to get past the arm 
>target build failure. Now it fails (during dyngen check) on ppc target, the 
>culprit is the following function:

Just keep the instruction after retl, if it's not a nop. Stack adjustments 
could be combined someplace, but that's a problem with all architectures, 
not just sparc.

That is:
insn1
retl
insn3

should become:
insn1
insn2

In some cases there is just one instruction after retl with nothing before 
it.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

[Qemu-devel] Re: Some patches for qemu on sparc

[Jurij Smakov]

On Sat, 11 Feb 2006, Blue Swirl wrote:

>> Thanks for your feedback. I've added additional check to dyngen.c, which 
>> checks that function has either save; in the beginning and ret; restore;
>> in the end, or ends in retl; nop;. That allowed me to get past the arm 
>> target build failure. Now it fails (during dyngen check) on ppc target, the 
>> culprit is the following function:
>
> Just keep the instruction after retl, if it's not a nop. Stack adjustments 
> could be combined someplace, but that's a problem with all architectures, not 
> just sparc.
>
> That is:
> insn1
> retl
> insn3
>
> should become:
> insn1
> insn2
>
> In some cases there is just one instruction after retl with nothing before 
> it.

Sorry, I am not familiar with qemu internals enough to understand that. It 
currently fails the build in the sanity check implemented in dyngen.c. We 
figured out so far that there might be two valid cases: save;...ret;restore;
and ....;retl;nop;. Are you saying that the function ending in 
retl;some_insn; is valid as well and the check has to be modified yet 
again to accomodate this (third) case?

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

[Qemu-devel] Re: Some patches for qemu on sparc

[Blue Swirl]

>Sorry, I am not familiar with qemu internals enough to understand that. It 
>currently fails the build in the sanity check implemented in dyngen.c. We 
>figured out so far that there might be two valid cases: 
>save;...ret;restore;
>and ....;retl;nop;. Are you saying that the function ending in 
>retl;some_insn; is valid as well and the check has to be modified yet again 
>to accomodate this (third) case?

Yes, though the second case can be seen a special case of the third.

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

[Qemu-devel] Re: Some patches for qemu on sparc

[Jurij Smakov]

On Sun, 12 Feb 2006, Blue Swirl wrote:

>> Sorry, I am not familiar with qemu internals enough to understand that. It 
>> currently fails the build in the sanity check implemented in dyngen.c. We 
>> figured out so far that there might be two valid cases: 
>> save;...ret;restore;
>> and ....;retl;nop;. Are you saying that the function ending in 
>> retl;some_insn; is valid as well and the check has to be modified yet again 
>> to accomodate this (third) case?
>
> Yes, though the second case can be seen a special case of the third.

Right. I've modified the check and now it goes further in the build. The 
next failure I'm hitting is:

make[2]: Entering directory `/home/jurij/qemu/qemu-0.8.0/i386-softmmu'
gcc-3.4 -Wall -O2 -g -fno-strict-aliasing -m32 -ffixed-g1 -ffixed-g2 
-ffixed-g3 -ffixed-g6 -I. -I/home/jurij/qemu/qemu-0.8.0/./target-i386 
-I/home/jurij/qemu/qemu-0.8.0/. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 
-D_LARGEFILE_SOURCE -I/home/jurij/qemu/qemu-0.8.0/./fpu -DHAS_AUDIO 
-I/home/jurij/qemu/qemu-0.8.0/./slirp -c -o vl.o 
/home/jurij/qemu/qemu-0.8.0/./vl.c
/home/jurij/qemu/qemu-0.8.0/./vl.c:552:2: #error unsupported CPU
/home/jurij/qemu/qemu-0.8.0/./vl.c: In function `cpu_get_ticks':
/home/jurij/qemu/qemu-0.8.0/./vl.c:563: warning: implicit declaration of 
function `cpu_get_real_ticks'
make[2]: *** [vl.o] Error 1
make[2]: Leaving directory `/home/jurij/qemu/qemu-0.8.0/i386-softmmu'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/jurij/qemu/qemu-0.8.0'
make: *** [debian/stamp-makefile-build] Error 2

Looks like there is no cpu_get_real_ticks() function implementation for 
sparc. There is an old message on qemu-devel discussing this issue [0].
It looks like this function is fairly easy to implement by reading the
%tick register in machines compliant with SPARC v9 architecture (Ultra1
or better), however the implementation for v8 architecture (and we are 
building binaries for v8 in Debian) does not look so simple. I'd 
appreciate any opinions or hints on this matter.

Best regards,

Jurij Smakov                                        jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/                   KeyID: C99E03CC

[Qemu-devel] Re: Some patches for qemu on sparc

[Blue Swirl]

>Looks like there is no cpu_get_real_ticks() function implementation for 
>sparc. There is an old message on qemu-devel discussing this issue [0].
>It looks like this function is fairly easy to implement by reading the
>%tick register in machines compliant with SPARC v9 architecture (Ultra1
>or better), however the implementation for v8 architecture (and we are 
>building binaries for v8 in Debian) does not look so simple. I'd appreciate 
>any opinions or hints on this matter.

Slavio timer can be programmed to free run (user profiler) and with suitable 
permissions, user programs can map the timer count register to their address 
space and read the timer count value. I don't know what Linux does in this 
respect.

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar - get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/