Re: [sqlite] Possible bug regarding endiannes and real storageclass (sqlite3)
> ARM has at least two FL formats. Yes, I'm currently rebuilding my crosscompiler with specific soft-float options, but it'll take a while. Also, it seems that apart from the endiannes of the processor, there's also 'endiannes of peripheral wiring', i.e. the way the memory is connected to the processor. At the moment I have no tech data on that regarding this particular machine. -- Best, Frank.
Re[2]: [sqlite] Possible bug regarding endiannes and real storageclass (sqlite3)
See http://lists.debian.org/debian-arm/2003/10/msg00030.html ARM has at least two FL formats. > from the ARM Architecture Reference Manual, Page C2-4: > > "The word order [for DP format] defined here for the VFP architecture > differs from that of the earlier FPA floating-point architecture. In > the FPA architecture, the most significant word always appeared at the > lower memory address, with the least significant word at the higher, > regardless of the memory system endianess". e
Re: [sqlite] Possible bug regarding endiannes and real storageclass (sqlite3)
Hi, > My test code is below. Please run this on your ARM and let > me know what you get. # ./test f03f 0100 It's getting smelly.. 32 bits only? -- Best, Frank.
Re: [sqlite] Possible bug regarding endiannes and real storageclass (sqlite3)
On Thu, 2005-08-18 at 14:10 -0400, D. Richard Hipp wrote: > On Thu, 2005-08-18 at 09:40 -0700, Robert Simpson wrote: > > http://www.psc.edu/general/software/packages/ieee/ieee.html > > > > The way I interpreted this site, is that the IEEE standard for floating > > point numbers was processor agnostic and the storage of the bits went from > > left to right. > > > > I wrote a test program to print out the byte values for 1.0 and 1 > on both ix86 (Intel, Linux) and powerpc (G5, OS-X). The results: > > ix86: f03f 0100 > powerpc: 3ff0 0001 > > This seems to validate the approach taken by SQLite, which is to > byteswap floating point values on ix86 machines. > As a double-check, I have confirmed that floating-point values written into an SQLite3 database file written on intel/linux are readable on max/os-x and vice versa. -- D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] Possible bug regarding endiannes and real storageclass (sqlite3)
On Thu, 2005-08-18 at 09:40 -0700, Robert Simpson wrote:
> http://www.psc.edu/general/software/packages/ieee/ieee.html
>
> The way I interpreted this site, is that the IEEE standard for floating
> point numbers was processor agnostic and the storage of the bits went from
> left to right.
>
I wrote a test program to print out the byte values for 1.0 and 1
on both ix86 (Intel, Linux) and powerpc (G5, OS-X). The results:
ix86: f03f 0100
powerpc: 3ff0 0001
This seems to validate the approach taken by SQLite, which is to
byteswap floating point values on ix86 machines.
My test code is below. Please run this on your ARM and let me
know what you get.
union utest {
double r;
long long i;
unsigned char z[8];
};
int main(int argc, char **argv){
union utest x;
x.r = 1.0;
printf("%02x%02x%02x%02x%02x%02x%02x%02x\n",
x.z[0], x.z[1], x.z[2], x.z[3], x.z[4], x.z[5], x.z[6], x.z[7]);
x.i = 1;
printf("%02x%02x%02x%02x%02x%02x%02x%02x\n",
x.z[0], x.z[1], x.z[2], x.z[3], x.z[4], x.z[5], x.z[6], x.z[7]);
return 0;
}
--
D. Richard Hipp <[EMAIL PROTECTED]>
Re: [sqlite] Possible bug regarding endiannes and real storageclass (sqlite3)
Original Message - From: "D. Richard Hipp" <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> Sent: Thursday, August 18, 2005 9:24 AM Subject: Re: [sqlite] Possible bug regarding endiannes and real storageclass (sqlite3) On Thu, 2005-08-18 at 18:04 +0200, Frank van Vugt wrote: L.S. It looks like there's something wrong with the endiannes when using sqlite3 (v3.2.2) on an ARM architecture (SA1100 nanoboard) while storing floating point data. SQLite assumes float point values are stored in the IEEE 64-bit format with the same byte order as the machine integer. http://www.psc.edu/general/software/packages/ieee/ieee.html The way I interpreted this site, is that the IEEE standard for floating point numbers was processor agnostic and the storage of the bits went from left to right. Robert
