Re: [sqlite] Possible bug regarding endiannes and realstorageclass (sqlite3)

[Frank van Vugt]

L.S.

In order to wrap this up: apparently there's a feature / bug (choose one) in 
any ARM core earlier than v5 due to which a float will be stored in big 
endian quad order. The processor in this particular case is an SA1110, which 
is default little endian while having a v4 core. (and thus is 'swapping' 
the quads).

> [Doug Currie] So for your ARM FP library, the code goes from

For the part that reads the data it's just semantics, really, but I'm using 
the patch now (against v3.2.3):

--- vdbeaux.c_orig  2005-08-22 21:32:53.0 +0200
+++ vdbeaux.c   2005-08-22 21:39:46.0 +0200
@@ -1649,7 +1649,11 @@
 }
 len = i = sqlite3VdbeSerialTypeLen(serial_type);
 while( i-- ){
-  buf[i] = (v&0xFF);
+  if( serial_type==7 ){
+buf[(i+4)%8] = (v&0xFF);
+  }else{
+buf[i] = (v&0xFF);
+  }
   v >>= 8;
 }
 return len;
@@ -1708,18 +1712,20 @@
   pMem->flags = MEM_Int;
   return 6;
 }
-case 6:   /* 8-byte signed integer */
-case 7: { /* IEEE floating point */
+case 6: { /* 8-byte signed integer */
   u64 x = (buf[0]<<24) | (buf[1]<<16) | (buf[2]<<8) | buf[3];
   u32 y = (buf[4]<<24) | (buf[5]<<16) | (buf[6]<<8) | buf[7];
   x = (x<<32) | y;
-  if( serial_type==6 ){
-pMem->i = *(i64*)
-pMem->flags = MEM_Int;
-  }else{
-pMem->r = *(double*)
-pMem->flags = MEM_Real;
-  }
+  pMem->i = *(i64*)
+  pMem->flags = MEM_Int;
+  return 8;
+}
+case 7: { /* IEEE floating point */
+  u64 x = (buf[4]<<24) | (buf[5]<<16) | (buf[6]<<8) | buf[7];
+  u32 y = (buf[0]<<24) | (buf[1]<<16) | (buf[2]<<8) | buf[3];
+  x = (x<<32) | y;
+  pMem->r = *(double*)
+  pMem->flags = MEM_Real;
   return 8;
 }
 default: {

>> [D. Richard Hipp] The code shown was for reading the database.
>> You'll also need to find and fix the spot where the database is written
> Obviously, but thanks for the heads-up anyway ;);)

The patch above includes that.



-- 
Best,




Frank.

Re: [sqlite] Possible bug regarding endiannes and realstorageclass (sqlite3)

[D. Richard Hipp]

On Thu, 2005-08-18 at 23:08 +0200, Frank van Vugt wrote:
> > Right. So for your ARM FP library, the code goes from 
> 
> Yep, will try that patch tomorrow morning, the soft-float cross-compiler 
> should be ready then as well, so we'll see if that makes any difference as 
> well.

The code shown was for reading the database.  You'll also need
to find and fix the spot where the database is written, of course.
-- 
D. Richard Hipp <[EMAIL PROTECTED]>

Re: [sqlite] Possible bug regarding endiannes and realstorageclass (sqlite3)

[Frank van Vugt]

> Right. So for your ARM FP library, the code goes from 

Yep, will try that patch tomorrow morning, the soft-float cross-compiler 
should be ready then as well, so we'll see if that makes any difference as 
well.





-- 
Best,




Frank.

Re: [sqlite] Possible bug regarding endiannes and realstorageclass (sqlite3)

[Frank van Vugt]

I repeated the test using the value 1.2345678 in order to be able to identify 
the position of each byte:

linux i386:

1bde8342cac0f33f
0100



linux arm:

cac0f33f1bde8342
0100



So, it indeed looks like 32bits based middle-endian or something




-- 
Best,




Frank.

RE: [sqlite] Possible bug regarding endiannes and realstorageclass (sqlite3)

[Thomas Briggs]

   I can also confirm that the original test case posted works correctly
when moving the file from Linux to Sparc (Solaris) and PA-RISC (HP-UX). 

   -Tom

> -Original Message-
> From: D. Richard Hipp [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, August 18, 2005 2:21 PM
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Possible bug regarding endiannes and 
> realstorageclass (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]>
> 
>