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, binutils
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 (unimplementeds being
Al Viro writes:
On Tue, Jul 08, 2014 at 08:32:55PM +0100, Peter Maydell wrote:
On 8 July 2014 18:20, Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Jul 08, 2014 at 05:33:16PM +0100, Peter Maydell wrote:
snip
Again, gprof isn't particulary useful - kernel-side profilers are at least as
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~
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 so
On Tue, Jul 08, 2014 at 08:32:55PM +0100, Peter Maydell wrote:
On 8 July 2014 18:20, Al Viro v...@zeniv.linux.org.uk 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
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/arch/something? Is that
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 (which
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 8 July 2014 18:20, Al Viro v...@zeniv.linux.org.uk 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
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 and
Peter Maydell writes:
On 8 July 2014 17:13, Al Viro v...@zeniv.linux.org.uk wrote:
On Tue, Jul 08, 2014 at 09:05:10AM +0100, Peter Maydell wrote:
snip
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
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 8 July 2014 08:13, Al Viro v...@zeniv.linux.org.uk 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 -
On 07/08/2014 01:05 AM, Peter Maydell wrote:
On 8 July 2014 08:13, Al Viro v...@zeniv.linux.org.uk 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
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 glory in
On 8 July 2014 17:13, Al Viro v...@zeniv.linux.org.uk 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
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, for
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 keep the
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... So
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
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 where
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 handler.
How
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 touch, or
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 and
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; since
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 0x70001620
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 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 something
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))) {
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 -1?
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 maybe_overflow
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_not_zero
On 3 July 2014 23:47, Al Viro v...@zeniv.linux.org.uk 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);-
On Fri, Jul 04, 2014 at 12:05:37AM +0100, Peter Maydell wrote:
On 3 July 2014 23:47, Al Viro v...@zeniv.linux.org.uk 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
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 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 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 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
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 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
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 sucker,
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
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 to do some
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
and pushed it to
On 1 July 2014 18:50, Al Viro v...@zeniv.linux.org.uk 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
On 07/01/2014 11:23 AM, Peter Maydell wrote:
On 1 July 2014 18:50, Al Viro v...@zeniv.linux.org.uk 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
On 1 July 2014 19:30, Richard Henderson r...@twiddle.net 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
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 v...@zeniv.linux.org.uk wrote:
Which glibc version? Better yet, could you throw preprocessed source
my way? UP1000 box is not in a good shape and
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 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 you've a helper
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 would be
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 ==
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
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 the tcg ops
On 25 June 2014 08:01, Al Viro v...@zeniv.linux.org.uk 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,
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_denormal
On 25 June 2014 15:26, Al Viro v...@zeniv.linux.org.uk 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
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(halt, void,
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
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 familiar
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,
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 signaled.
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, and I'm pretty
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 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 fans,
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~
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 and a lot of crap needed to satisfy build-deps of those, plus
68 matches
Mail list logo
