On Tue, Jul 08, 2014 at 08:32:55PM +0100, Peter Maydell wrote:
On 8 July 2014 18:20, Al Viro wrote:
> > On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote:
> >
> >> > Incidentally, combination of --enable-gprof and (default) --enable-pie
> >> > won't build - it dies with ld(1) complain
On Mon, Jul 07, 2014 at 11:03:08PM -0700, Richard Henderson wrote:
> On 07/07/2014 09:20 PM, Al Viro wrote:
> > and I'm reasonably sure that this is what they did internally. You are
> > proposing to do 4 cases in all their messy glory in qemu itself...
>
> Yes. Primarily because we *have* to do
On 07/08/2014 10:47 PM, Al Viro wrote:
> So env->fpcr_flush_to_zero = env->fpcr_dnod & env->fpcr_undz; is another
> bug - needs s/dnod/unfd/ there...
That's exactly what I was looking at, thanks.
r~
Al Viro writes:
> On Tue, Jul 08, 2014 at 08:32:55PM +0100, Peter Maydell wrote:
> On 8 July 2014 18:20, Al Viro wrote:
>> > On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote:
> Again, gprof isn't particulary useful - kernel-side profilers are at least as
> good. So I suspect that
On Wed, Jul 09, 2014 at 08:14:12AM -0700, Richard Henderson wrote:
> On 07/08/2014 10:47 PM, Al Viro wrote:
> > So env->fpcr_flush_to_zero = env->fpcr_dnod & env->fpcr_undz; is another
> > bug - needs s/dnod/unfd/ there...
>
> That's exactly what I was looking at, thanks.
BTW, that (unimplemented
On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote:
> > Incidentally, combination of --enable-gprof and (default) --enable-pie
> > won't build - it dies with ld(1) complaining about relocs in gcrt1.o.
>
> This sounds like a toolchain bug to me :-)
Debian stable/amd64, gcc 4.7.2, binut
Peter Maydell writes:
> On 8 July 2014 17:13, Al Viro wrote:
>> On Tue, Jul 08, 2014 at 09:05:10AM +0100, Peter Maydell wrote:
>>
>> BTW, are there any more or less uptodate docs on qemu profiling? I mean,
>> things like perf/oprofile on the host obviously end up lumping all tcg
>> output toge
On 07/08/2014 01:20 PM, Al Viro wrote:
> Aha... So you've caught that one already... I've looked at your branch;
> AFAICS, the only thing missing there is treating stores to FPCR.DNOD in
> system mode as "not implemented" (which it is in the code as well as in
> 21[0-3]64 hardware).
Is it loaded
On 8 July 2014 18:20, Al Viro wrote:
> On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote:
>
>> > Incidentally, combination of --enable-gprof and (default) --enable-pie
>> > won't build - it dies with ld(1) complaining about relocs in gcrt1.o.
>>
>> This sounds like a toolchain bug to m
On 07/08/2014 09:13 AM, Al Viro wrote:
> Frankly, I suspect that it's better to have qemu-system-alpha behave like
> the actual hardware does (including "FPCR.DNOD can't be set") and keep the
> linux-user behaviour as is, for somebody brave and masochistic enough to
> fight that one. And no, it's
On Tue, Jul 08, 2014 at 09:59:33PM -0700, Richard Henderson wrote:
> On 07/08/2014 01:20 PM, Al Viro wrote:
> > Aha... So you've caught that one already... I've looked at your branch;
> > AFAICS, the only thing missing there is treating stores to FPCR.DNOD in
> > system mode as "not implemented"
On Tue, Jul 08, 2014 at 09:05:10AM +0100, Peter Maydell wrote:
> The code we have currently may well be buggy, but the correct
It is ;-/ We set TARGET_FPE_FLTINV unconditionally there. BTW, what's
the reason why all these cpu_loop() instances can't go into
linux-user//something? Is that just b
On Tue, Jul 08, 2014 at 12:04:10PM -0700, Richard Henderson wrote:
> > Just one thing - 0x1f will make 32bit hosts whine about integer
> > constant being too large. So will 0x1ful, unfortunately - it
> > really ought to be ull.
> >
>
> I did use ull on the branch.
Aha..
On 07/08/2014 12:02 PM, Al Viro wrote:
> On Tue, Jul 08, 2014 at 11:12:20AM -0700, Richard Henderson wrote:
>> On 07/08/2014 09:13 AM, Al Viro wrote:
>>> Frankly, I suspect that it's better to have qemu-system-alpha behave like
>>> the actual hardware does (including "FPCR.DNOD can't be set") and k
On Tue, Jul 08, 2014 at 11:12:20AM -0700, Richard Henderson wrote:
> On 07/08/2014 09:13 AM, Al Viro wrote:
> > Frankly, I suspect that it's better to have qemu-system-alpha behave like
> > the actual hardware does (including "FPCR.DNOD can't be set") and keep the
> > linux-user behaviour as is, fo
On 8 July 2014 17:13, Al Viro wrote:
> On Tue, Jul 08, 2014 at 09:05:10AM +0100, Peter Maydell wrote:
>
>> The code we have currently may well be buggy, but the correct
>
> It is ;-/ We set TARGET_FPE_FLTINV unconditionally there. BTW, what's
> the reason why all these cpu_loop() instances can't
On Tue, Jul 08, 2014 at 07:54:36AM +0100, Al Viro wrote:
> On Mon, Jul 07, 2014 at 11:03:08PM -0700, Richard Henderson wrote:
> > On 07/07/2014 09:20 PM, Al Viro wrote:
> > > and I'm reasonably sure that this is what they did internally. You are
> > > proposing to do 4 cases in all their messy glo
On 07/08/2014 01:05 AM, Peter Maydell wrote:
> On 8 July 2014 08:13, Al Viro wrote:
>> Actually, that's badly worded; what codepath ends up setting si_code on
>> e.g. fp addition overflows? In system mode it's done by completion code
>> in the kernel, but AFAICS in user mode there are only two pl
On 8 July 2014 08:13, Al Viro wrote:
> Actually, that's badly worded; what codepath ends up setting si_code on
> e.g. fp addition overflows? In system mode it's done by completion code
> in the kernel, but AFAICS in user mode there are only two places where it
> might happen - one is gentrap hand
On 07/07/2014 09:20 PM, Al Viro wrote:
> and I'm reasonably sure that this is what they did internally. You are
> proposing to do 4 cases in all their messy glory in qemu itself...
Yes. Primarily because we *have* to do so for the linux-user case.
> And that's not even going into generating the
On Mon, Jul 07, 2014 at 09:20:28AM -0700, Richard Henderson wrote:
> > How is that different from other cases where we have an exception raised
> > by an fp operation?
>
> In all other cases we know we're going to send SIGFPE. That's either through
> a
> non /S insn which the kernel wouldn't tou
On 07/07/2014 08:06 AM, Al Viro wrote:
> On Mon, Jul 07, 2014 at 07:11:58AM -0700, Richard Henderson wrote:
>> A couple of points here:
>>
>> 1) We should never raise this in user-only mode. In that mode, we emulate
>> the
>> whole fpu stack, all the way through from HW to the OS completion handl
On Mon, Jul 07, 2014 at 07:11:58AM -0700, Richard Henderson wrote:
> A couple of points here:
>
> 1) We should never raise this in user-only mode. In that mode, we emulate the
> whole fpu stack, all the way through from HW to the OS completion handler.
How is that different from other cases wher
On 07/05/2014 03:55 PM, Al Viro wrote:
> +/* Input handing with software completion. Trap for denorms,
> + unless DNZ is set. *IF* we try to support DNOD (which
> + none of the produced hardware did, AFAICS), we'll need
> + to suppress the trap when FPCR.DNOD is set; then the
> + code dow
On Sat, Jul 05, 2014 at 10:09:51PM +0100, Al Viro wrote:
> Anyway, the current delta (on top of 26f86) follows; seems to get IEEE
> insns behave on non-finite arguments as they do on 21264. The main
> exception is that register bitmask supplied to trap isn't calculated in
> a bunch of cases; sinc
On Sat, Jul 05, 2014 at 02:40:55AM +0100, Al Viro wrote:
> a) softfloat.c raises flags we don't care about. So checking that
> FP_STATUS.float_exception_flags is non-zero is *not* good - we catch
> false positives that way.
>
> b) DNZ has effect *only* for /S insns. Without /S denorm means INV a
On Sat, Jul 05, 2014 at 02:40:55AM +0100, Al Viro wrote:
> d) at least on EV6 and EV67 DNOD *still* trips INV. According to the
> manual suppression of INV by DNOD is optional. And while their text
> might be interpreted as "INV is suppressed if operation with denorm
> wouldn't result in somethin
Denorms fun:
a) softfloat.c raises flags we don't care about. So checking that
FP_STATUS.float_exception_flags is non-zero is *not* good - we catch
false positives that way.
b) DNZ has effect *only* for /S insns. Without /S denorm means INV and
that's it. FPCR.INV isn't set, at that.
On Thu, Jul 03, 2014 at 09:30:05PM -0700, Richard Henderson wrote:
> > Another one is probably not worth bothering - PERR, CTPOP, CTLZ, UNPKBx and
> > PKxB
> > don't accept literal argument. For one thing, as(1) won't let you generate
> > those, so it would have to be explicit
> > .long 0x70
On 07/03/2014 05:50 PM, Al Viro wrote:
> OK, looks sane. Next (trivial) bug: in translate_one()
> case 0xF800:
> /* WH64 */
> /* No-op */
> break;
> should be followed by
> case 0xFC00:
> /* WH64EN */
> /* No-op */
>
On Thu, Jul 03, 2014 at 01:19:19PM -0700, Richard Henderson wrote:
> I believe I have a tidy solution to these /v insns. New patch set shortly.
OK, looks sane. Next (trivial) bug: in translate_one()
case 0xF800:
/* WH64 */
/* No-op */
break;
should be
On Fri, Jul 04, 2014 at 12:05:37AM +0100, Peter Maydell wrote:
> On 3 July 2014 23:47, Al Viro wrote:
> > How can that be correct? Suppose a = b = 0. We get
> > tcg_gen_eqv_i64(tmp, va, vb); -> tmp = -1
> > tcg_gen_mov_i64(tmp2, va); -> tmp2 = 0
> > tcg_gen_add_i64(vc, va, vb);
On 3 July 2014 23:47, Al Viro wrote:
> How can that be correct? Suppose a = b = 0. We get
> tcg_gen_eqv_i64(tmp, va, vb); -> tmp = -1
> tcg_gen_mov_i64(tmp2, va); -> tmp2 = 0
> tcg_gen_add_i64(vc, va, vb);-> c = 0
> tcg_gen_xor_i64(tmp2, tmp2, vc);-> tmp2 = 0
> tcg
On Thu, Jul 03, 2014 at 01:19:19PM -0700, Richard Henderson wrote:
> > Grr... Wrong check, obviously - we want to check that tmp + MSB(tmp2) is 0.
> > Something like
> > setcond_32 tmp2, tmp2, zero, TCG_COND_LT
> > add_i32 tmp, tmp2, tmp
> > callhelper_IOV_if_n
On 07/03/2014 11:25 AM, Al Viro wrote:
> On Thu, Jul 03, 2014 at 07:51:04AM +0100, Al Viro wrote:
>
>> FWIW, why not just generate
>> trunc_i64_i32 tmp, va
>> trunc_i64_i32 tmp2, vb
>> muls2_i32 tmp2, tmp, tmp, tmp2
>> ext32s_i64 vc, tmp2
>> maybe_overflow_32 tmp
>> where
On Thu, Jul 03, 2014 at 07:51:04AM +0100, Al Viro wrote:
> FWIW, why not just generate
> trunc_i64_i32 tmp, va
> trunc_i64_i32 tmp2, vb
> muls2_i32 tmp2, tmp, tmp, tmp2
> ext32s_i64 vc, tmp2
> maybe_overflow_32 tmp
> where maybe_overflow throws IOV unless tmp is 0 or
More bugs: addl/v should sign-extend the result, as addl does.
As it is, we have
uint64_t helper_addlv(CPUAlphaState *env, uint64_t op1, uint64_t op2)
{
uint64_t tmp = op1;
op1 = (uint32_t)(op1 + op2);
if (unlikely((tmp ^ op2 ^ (-1UL)) & (tmp ^ op1) & (1UL << 31))) {
ari
On Wed, Jul 02, 2014 at 08:26:53AM -0700, Richard Henderson wrote:
> On 07/01/2014 11:17 PM, Al Viro wrote:
> > If we don't want FE_INEXACT seen by fetestexcept() after rounding 4.5, we'd
> > better not use FPCR.INE - *all* variants of actual hardware (at least from
> > 21064A to 21264) set that su
On 07/01/2014 11:17 PM, Al Viro wrote:
> If we don't want FE_INEXACT seen by fetestexcept() after rounding 4.5, we'd
> better not use FPCR.INE - *all* variants of actual hardware (at least from
> 21064A to 21264) set that sucker, and 4.7 in Architecture Reference Manual
> very clearly requires such
> I'm interested in the results of the following test.
DS10:
/su : 1/3 -i---
/sui : 1/3 -i---
/su : min*min -i--u
/sui : min*min -i--u
/: (long)4.5 -i---
/sv : (long)4.5 -i---
/svi : (long)4.5 -i---
/: (long)max -i---
/sv : (long)max
On 07/01/2014 09:05 PM, Al Viro wrote:
> Which glibc version it is? I don't see such failures with your
> axp/axp-next (head at 6b38f4e7f); could you post the details on your
> reproducer? I've tried to guess the likely version by glibc.git, but
> I don't see nearbyint tests with such argument in
On Wed, Jul 02, 2014 at 06:50:27AM +0100, Al Viro wrote:
> AFAICS, it leaves two possibilities - EV45 (AS200) vs. EV6 (DS10) and EV67
> (qemu) _or_ some change in the kernel. I'll build 3.x kernel for DS10 and
> post the results; shouldn't take long...
Actually, it's simpler - note that on *all*
On Wed, Jul 02, 2014 at 05:05:08AM +0100, Al Viro wrote:
> OK, DS10 resurrected and so far seems to be stable (I'll know by tomorrow;
> there's a possibility that chipset heatsink is dodgy, but so far it seems
> to be doing OK). That gives us a EV6 box.
>
> Which glibc version it is? I don't see
On Tue, Jul 01, 2014 at 11:30:19AM -0700, Richard Henderson wrote:
> On 07/01/2014 11:23 AM, Peter Maydell wrote:
> > On 1 July 2014 18:50, Al Viro wrote:
> >> Which glibc version? Better yet, could you throw preprocessed source
> >> my way? UP1000 box is not in a good shape and I'd rather avoid
On 1 July 2014 19:30, Richard Henderson wrote:
> On 07/01/2014 11:23 AM, Peter Maydell wrote:
>> Would a 164LX be a useful (ie non-duplicate) extra resource
>> for testing this stuff? That has a 21164 (EV5) in it. I haven't
>> tried to boot it for some years, but I can have a try at
>> resurrectin
On 07/01/2014 11:23 AM, Peter Maydell wrote:
> On 1 July 2014 18:50, Al Viro wrote:
>> Which glibc version? Better yet, could you throw preprocessed source
>> my way? UP1000 box is not in a good shape and I'd rather avoid trying to run
>> full glibc builds on it ;-/
>
> Would a 164LX be a usefu
On 1 July 2014 18:50, Al Viro wrote:
> Which glibc version? Better yet, could you throw preprocessed source
> my way? UP1000 box is not in a good shape and I'd rather avoid trying to run
> full glibc builds on it ;-/
Would a 164LX be a useful (ie non-duplicate) extra resource
for testing this s
On Tue, Jul 01, 2014 at 10:03:06AM -0700, Richard Henderson wrote:
> On 06/30/2014 01:56 PM, Al Viro wrote:
> > On Mon, Jun 30, 2014 at 11:39:43AM -0700, Richard Henderson wrote:
> >
> >> Looks good.
> >>
> >> I've split it up into a couple of smaller patches, made some sylistic
> >> tweaks
> >>
On 06/30/2014 01:56 PM, Al Viro wrote:
> On Mon, Jun 30, 2014 at 11:39:43AM -0700, Richard Henderson wrote:
>
>> Looks good.
>>
>> I've split it up into a couple of smaller patches, made some sylistic tweaks
>> and pushed it to
>>
>> git://github.com/rth7680/qemu.git axp-next
>>
>> I'm starting
On 06/30/2014 09:34 PM, Al Viro wrote:
> VAX operations are serious mess, but I'm not sure if we have them actually
> used anywhere in Linux kernel or userland. Always possible, of course, but...
As far as I know, vax insns aren't used anywhere. If I were doing this port
from scratch I'd leave t
On Tue, Jul 01, 2014 at 05:34:45AM +0100, Al Viro wrote:
> VAX operations are serious mess, but I'm not sure if we have them actually
> used anywhere in Linux kernel or userland. Always possible, of course, but...
Grr... Truncated mail, sorry. Missing part:
_If_ we decide that we want CVTGQ w
On Mon, Jun 30, 2014 at 09:56:35PM +0100, Al Viro wrote:
> FWIW, it might be better to do what float64_to_int64_round_to_zero() is doing
> -
> i.e.
> if (shift >= 0) {
> if (shift < 64)
> ret = frac << shift;
> if (shift < 11 || a == LIT64(0x
On Mon, Jun 30, 2014 at 11:39:43AM -0700, Richard Henderson wrote:
> Looks good.
>
> I've split it up into a couple of smaller patches, made some sylistic tweaks
> and pushed it to
>
> git://github.com/rth7680/qemu.git axp-next
>
> I'm starting to do some testing now, but a glance though woul
On 06/25/2014 10:55 PM, Al Viro wrote:
> On Wed, Jun 25, 2014 at 08:01:17AM +0100, Al Viro wrote:
>> On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote:
>>> On 06/24/2014 02:24 PM, Al Viro wrote:
Al, off to figure out the black magic TCG is using to generate calls...
>>>
>>> If
On Wed, Jun 25, 2014 at 08:01:17AM +0100, Al Viro wrote:
> On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote:
> > On 06/24/2014 02:24 PM, Al Viro wrote:
> > > Al, off to figure out the black magic TCG is using to generate calls...
> >
> > If you've a helper
> >
> > DEF_HELPER_1(ha
On 25 June 2014 15:26, Al Viro wrote:
> Hmm... On alpha it's generated only by the following: CVTTQ, CVTGQ,
> CVTQL. I.e. conversions to integer formats that can be held in FPU
> registers (double -> s64, VAX double -> s64 and s64 -> s32). Does
> softfloat even have anything similar?
Well, VAX
On Wed, Jun 25, 2014 at 10:27:11AM +0100, Peter Maydell wrote:
> I think it's OK to put extra float_flags in, provided you can define
> their semantics in terms that make sense for more than one
> architecture (even if only one arch actually happens to need them).
> The input_denormal/output_denor
On 25 June 2014 08:01, Al Viro wrote:
> Could we steal bit 1 in float_exception_flags for IOV? It is (currently?)
> unused -
> enum {
> float_flag_invalid = 1,
> float_flag_divbyzero = 4,
> float_flag_overflow = 8,
> float_flag_underflow = 16,
> float_flag_inexact = 32
On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote:
> On 06/24/2014 02:24 PM, Al Viro wrote:
> > Al, off to figure out the black magic TCG is using to generate calls...
>
> If you've a helper
>
> DEF_HELPER_1(halt, void, i64)
>
> then
>
> gen_helper_halt(...)
>
> will generate
On 06/24/2014 02:24 PM, Al Viro wrote:
> Al, off to figure out the black magic TCG is using to generate calls...
If you've a helper
DEF_HELPER_1(halt, void, i64)
then
gen_helper_halt(...)
will generate the tcg ops that result in the call.
r~
On Tue, Jun 24, 2014 at 01:57:52PM -0700, Richard Henderson wrote:
> On 06/24/2014 01:32 PM, Al Viro wrote:
> > If you have any ideas for testing, I do have working hw (the box that is
> > currently alive is ev45, though; I _can_ try to boot a UP1000 one, but
> > I make no promises regarding its fa
On 06/24/2014 01:32 PM, Al Viro wrote:
> If you have any ideas for testing, I do have working hw (the box that is
> currently alive is ev45, though; I _can_ try to boot a UP1000 one, but
> I make no promises regarding its fans, both in PSU and in CPU module ;-/)
Ah. Gotta be careful with ev4/45..
On Tue, Jun 24, 2014 at 11:23:01AM -0700, Richard Henderson wrote:
> > env->error_code = error;
> > if (retaddr) {
> > cpu_restore_state(cs, retaddr);
> > + env->pc += 4;
>
> This one needs a different fix, since dynamic_excp is also used from
> alpha_cpu_unassigned_access, an
On Tue, Jun 24, 2014 at 11:33:32AM -0700, Richard Henderson wrote:
> > return (unsigned long)x;// SVCTQ/SVC
CVTTQ/SVC, of course...
> Clearly a gross misunderstanding of what bits are actually computed, never
> mind
> what gets signale
On 06/24/2014 09:52 AM, Al Viro wrote:
> unsigned long __attribute__((noinline)) f(double x)
> {
> return (unsigned long)x;// SVCTQ/SVC
> }
>
> main()
> {
> unsigned long x;
> extern unsigned long __ieee_get_fp_control(void);
> printf("before:%lx\n", __ieee_
On 06/23/2014 09:34 PM, Al Viro wrote:
> Anyway, delta that seems to fix the gcc one (gcc.dg/pr28796-2.c from
> gcc-4.3 and later) follows. Again, I'm not at all sure if handling of
> env->pc in there is safe from qemu POV and I'd like like to get comments on
> that from somebody more famili
On Tue, Jun 24, 2014 at 05:34:23AM +0100, Al Viro wrote:
> First of all, kudos - with current qemu tree qemu-alpha-system is
> working pretty well - debian install and a *lot* of builds work just fine.
> As in, getting from lenny to pretty complete squeeze toolchain, including gcj,
> openjdk6
67 matches
Mail list logo
