Changes between Version 11 and Version 12 of PortableRrdFormat

Timestamp:

Jun 20, 2007, 11:12:01 PM (15 years ago)

Author:

oetiker

Comment:

Added ARM information

PortableRrdFormat

@@ -7 +7 @@
 The downside of this is, that data can in general not be accessed from two different HW/OS combinations.
 
-There are some provisions in RRD to detect such cross architecture access. But detection is not perfect. Some combinations are bound to even almost work. SPARC to PPC only differs in the representation of NANs.
+There are some provisions in RRD to detect such cross architecture access. But detection is not perfect. Some combinations are bound to even almost work. Most CPUS only
+differ in their representation of NANs.
 
 == Figuring 64bit Floating Point Numbers ==
@@ -121 +122 @@
 }}}
 
+ARMv4l
+{{{
+    0.000000e+00 ->  00 00 00 00 00 00 00 00
+    1.000000e+00 ->  00 00 f0 3f 00 00 00 00
+   -1.000000e+00 ->  00 00 f0 bf 00 00 00 00
+             nan ->  ff ff ff ff ff ff ff ff
+             inf ->  00 00 f0 7f 00 00 00 00
+            -inf ->  00 00 f0 ff 00 00 00 00
+    2.000000e+00 ->  00 00 00 40 00 00 00 00
+    4.000000e+00 ->  00 00 10 40 00 00 00 00
+    8.000000e+00 ->  00 00 20 40 00 00 00 00
+    1.600000e+01 ->  00 00 30 40 00 00 00 00
+   8.642135e+130 ->  43 2b 1f 5b 2f 25 c0 c7
+}}}
+
 As you can see, there is not all that much difference between the architectures (it is all IEEE 754 after all). For one there is the endianess difference and then there are the SPARCs how seem to have their own idea regarding NANs. In any event, a converter between these formats is only a few defines away.
 
@@ -132 +148 @@
                        (((uint64_t)(A) & 0x000000000000ff00LL) << 40) | \
                        (((uint64_t)(A) & 0x00000000000000ffLL) << 56))
-#define 
+
+#define intswap(A)    ((((uint64_t)(A) & 0xffffffff00000000LL) >> 32) | \
+                       (((uint64_t)(A) & 0x00000000ffffffffLL) << 32))
+
 #define sparc2x86(A)   ((uint64_t)(A) == 0x7fffffffffffffffLL \
                                        ? 0x000000000000f87fLL \
@@ -148 +167 @@
                                        ? 0x7ff4000000000000LL \
                                        : endianflip(A))
+
+#define ppc2x86(A)     endianflip(A)
+
+#define x862ppc(A)     endianflip(A)
+
+#define arm2x86(A)     ((uint64_t)(A) == 0xffffffffffffffffLL \
+                                       ? 0x000000000000f87fLL \
+                                       : intswap(A))
+
+#define x862arm(A)     ((uint64_t)(A) == 0x000000000000f87fLL \
+                                       ? 0xffffffffffffffffLL \
+                                       : intswap(A))
 
 #define itanium2x86(A) ((uint64_t)(A) == 0x000000000000f8ffLL \
@@ -157 +188 @@
                                        : A )
 
-#define ppc2x86(A)     endianflip(A)
-
-#define x862ppc(A)     endianflip(A)
 }}}
 
@@ -200 +228 @@
 
 Based on this information a portable RRDtool data format that works at least on
-PPC, x86 and SPARC will be not all that difficult to design.
-
-Information on other architectures is welcome: Alpha, ARM, MIPS. 
+PPC, x86, Itanium, PARISC, ARM and SPARC will be not all that difficult to design.
+
+Information on other architectures is welcome: Alpha, MIPS.