[Linux-Xtensa] xtensa - Unaligned.h and byteorder.h

linux-xtensa at linux-xtensa.org linux-xtensa at linux-xtensa.org
Fri Apr 3 05:19:31 PDT 2009


Hi Harvey:

I discussed at least one of these changes with you last year in
reference to problems compiling without optimization enabled.
Now I'm interested in the removal of some asm code...

You made two change sets between 2.6.27 and 2.6.29 that I'm wondering about.

91a15026eb89a687dfcac860a969cfd872f3c94f on  11/09/2008 06:51:09 PM
	arch/xtensa/include/asm/unaligned.h


367b8112fe2ea5c39a7bb4d263dcdd9b612fae18 on  01/07/2009 12:19:31 PM
	include/asm-xtensa/byteorder.h

You mentioned in the latter that this fixes compiler breakage as
linux/byteorder.h was removed.

I just merged with Emlix's git repo based on 2.6.29-rc7 with our NEW SMP
support and appear to have mono-processor working just as great as on 2.6.27.
However I'm getting a major instability in SMP and I'm starting to root causing
this problem.

Could you tell me what you recall of this compiler breakage problem
and why this asm code was removed?

  -------------------------------------------------------------------
-#define __SWAB_64_THRU_32__
-
-static inline __attribute_const__ __u32 __arch_swab32(__u32 x)
-{
-    __u32 res;
-    /* instruction sequence from Xtensa ISA release 2/2000 */
-    __asm__("ssai     8           \n\t"
-	    "srli     %0, %1, 16  \n\t"
-	    "src      %0, %0, %1  \n\t"
-	    "src      %0, %0, %0  \n\t"
-	    "src      %0, %1, %0  \n"
-	    : "=&a" (res)
-	    : "a" (x)
-	    );
-    return res;
-}
-#define __arch_swab32 __arch_swab32
-
-static inline __attribute_const__ __u16 __arch_swab16(__u16 x)
-{
-    /* Given that 'short' values are signed (i.e., can be negative),
-     * we cannot assume that the upper 16-bits of the register are
-     * zero.  We are careful to mask values after shifting.
-     */
-
-    /* There exists an anomaly between xt-gcc and xt-xcc.  xt-gcc
-     * inserts an extui instruction after putting this function inline
-     * to ensure that it uses only the least-significant 16 bits of
-     * the result.  xt-xcc doesn't use an extui, but assumes the
-     * __asm__ macro follows convention that the upper 16 bits of an
-     * 'unsigned short' result are still zero.  This macro doesn't
-     * follow convention; indeed, it leaves garbage in the upport 16
-     * bits of the register.
-
-     * Declaring the temporary variables 'res' and 'tmp' to be 32-bit
-     * types while the return type of the function is a 16-bit type
-     * forces both compilers to insert exactly one extui instruction
-     * (or equivalent) to mask off the upper 16 bits. */
-
-    __u32 res;
-    __u32 tmp;
-
-    __asm__("extui    %1, %2, 8, 8\n\t"
-	    "slli     %0, %2, 8   \n\t"
-	    "or       %0, %0, %1  \n"
-	    : "=&a" (res), "=&a" (tmp)
-	    : "a" (x)
-	    );
-
-    return res;
-}
-#define __arch_swab16 __arch_swab16
-
-#include <linux/byteorder.h>
----------------------------------------------------------------------------------------

I very much doubt the Enlix changes are involved in the SMP regression.
More likely something like header changes during my merge or something like
this asm code being dropped by your change.

-piet



More information about the linux-xtensa mailing list