freebsd-arm Digest, Vol 209, Issue 3
freebsd-a...@freebsd.org
freeb...@freebsd.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.freebsd.org/mailman/listinfo/freebsd-arm
or, via email, send a message with subject or body 'help' to
freebsd-a...@freebsd.org
You can reach the person managing the list at
freebsd-...@freebsd.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of freebsd-arm digest..."
Today's Topics:
1. Re: printf(long double) (M. Warner Losh)
2. Re: printf(long double) (Alexander Motin)
3. Re: ATA_CAM-ed mvsata(4) on OpenRD-client (Alexander Motin)
----------------------------------------------------------------------
Message: 1
Date: Tue, 30 Mar 2010 09:05:25 -0600 (MDT)
From: "M. Warner Losh" <i...@bsdimp.com>
Subject: Re: printf(long double)
To: m...@FreeBSD.org
Cc: freeb...@FreeBSD.org
Message-ID: <20100330.090525.956...@bsdimp.com>
Content-Type: Text/Plain; charset=us-ascii
In message: <4BB1C5C9...@FreeBSD.org>
Alexander Motin <m...@FreeBSD.org> writes:
: Hi.
:
: Playing with SheevaPlug (Marvell 88F6281 rev A0) with fresh 9-CURRENT
: I've found that many system statistics utilities are lying, showing
: number few times smaller then expected. After some investigation I've
: found that the problem possibly goes from different meaning of (long
: double) type for compiler and printf() code.
Yes. That's possible. Your code has some mis-match between printf
args, which most likely is causing problems.
: I've written small test to check it:
: #include <stdio.h>
: int
: main (void)
: {
: printf("%d %d\n", sizeof(long double), sizeof(double));
: printf("%Lf %f %Lf %f\n", (long double)14.5, (long double)14.5,
: (double)14.5, (double)14.5);
: }
:
: On amd64 it prints:
: # ./a.out
:
: But on arm:
: %./a.out
:
: Can somebody comment this?
amd64: 16 8
arm : 8 8
long double is only guaranteed to be as long as double, but may be
longer. Even on i386 it is really only 80 bits, even though you'd
think it should be 128 bits. On ARM we use soft floating point, so
long double is folded into double. There may be away to have 128-bit
floating point support, but nobody has climbed that hill for ARM or
for MIPS.
amd64: 14.500000 14.500000 14.500000 14.500000
arm : 6.500000 14.500000 6.500000 14.500000
First, your code gives warnings:
g.c:5: warning: format '%d' expects type 'int', but argument 2 has type 'long unsigned int'
g.c:5: warning: format '%d' expects type 'int', but argument 3 has type 'long unsigned int'
g.c:7: warning: format '%f' expects type 'double', but argument 3 has type 'long double'
g.c:7: warning: format '%Lf' expects type 'long double', but argument 4 has type 'double'
The first two are benign since the sizes are the same (long and int
are the same in both ABIs).
The second two show that two of the results should be wrong, depending
on the ABIs. Looking at the generated code on amd64, it looks like 8
bytes are used for each element passed into. But it also looks like
the floating point xmm registers are used, which is likely why it gets
things right. I don't know enough about the amd64 ABI to know if this
is a correct analysis, but likely is something close, since otherwise
I'd have expected the results to be wrong.
ARM should have passed the same size element for both the double and
the long double, but didn't. You should try fixing the printf and
running again. I don't have the ARM ABI docs handy to look it up, but
I know that some args are passed on the stack, while others are passed
in registers. This difference likely accounts for the numbers being
printed wrong.
On x86, we get:
12 8
14.500000 -9124881235244390437282343211400582649786457014497119861158385035798550334417354773011825622634742799557284619147188814621377409442750875996505322639444428376503989348720529900165748384493207552.000000 0.000000 14.500000
which doesn't look right to me. Fixing the warnings we get:
12 8
14.500000 14.500000 14.500000 14.500000
Warner
------------------------------
Message: 2
Date: Tue, 30 Mar 2010 18:39:22 +0300
From: Alexander Motin <m...@FreeBSD.org>
Subject: Re: printf(long double)
To: "M. Warner Losh" <i...@bsdimp.com>
Cc: freeb...@FreeBSD.org
Message-ID: <4BB21B2A...@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1
M. Warner Losh wrote:
> In message: <4BB1C5C9...@FreeBSD.org>
> Alexander Motin <m...@FreeBSD.org> writes:
> : Playing with SheevaPlug (Marvell 88F6281 rev A0) with fresh 9-CURRENT
> : I've found that many system statistics utilities are lying, showing
> : number few times smaller then expected. After some investigation I've
> : found that the problem possibly goes from different meaning of (long
> : double) type for compiler and printf() code.
>
> Yes. That's possible. Your code has some mis-match between printf
> args, which most likely is causing problems.
OK, it was wrong indeed. But that is not the reason, but coincidence.
Here is fixed code:
#include <stdio.h>
int
main (void)
{
printf("%Lf %f\n", (long double)14.5, (double)14.5);
return(0);
}
It compiles cleanly on both arm and amd64, but still not working on arm:
%./a.out
6.500000 14.500000
--
Alexander Motin
------------------------------
Message: 3
Date: Wed, 31 Mar 2010 10:25:38 +0300
From: Alexander Motin <m...@FreeBSD.org>
Subject: Re: ATA_CAM-ed mvsata(4) on OpenRD-client
To: Norikatsu Shigemura <no...@freebsd.org>
Cc: freeb...@freebsd.org, freebsd...@freebsd.org
Message-ID: <4BB2F8F2...@FreeBSD.org>
Content-Type: text/plain; charset=ISO-8859-1
Hi.
Norikatsu Shigemura wrote:
> I got a OpenRD-client (Marvell 88F6281 SoC), and I'm tring to
> make mvsata(4) ATA_CAM, like following:
>
> But I got following panic, my I help you?
> In this time, I attached no devices to SATA/eSATA port.
> - - - - - -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> ata1: <Marvell Integrated SATA Channel> on sata0
> ata1: [MPSAFE]
> ata1: [ITHREAD]
> spin lock 0xc3766680 (fvH) held by 0xc3613b48 (tid -1061308344) too long
> panic: spin lock held too long
> KDB: enter: panic
> [ thread pid 0 tid 100000 ]
> Stopped at 0xc09dcb50 = kdb_enter+0x48: ldrb r15, [r15, r15, ror r15]!
> db>
Fixed at SVN r205967.
--
Alexander Motin
------------------------------
End of freebsd-arm Digest, Vol 209, Issue 3
*******************************************