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)
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 s
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;s
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 (dur
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
cul
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 ch
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. T
> 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,
>
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
