Intel ecc compiler doesn't support inline assembly.
Attached patch is required to enable linux kernel build with Intel ecc compiler.
Please apply.
thanks,
suresh
diff -Nru linux/include/linux/compiler.h linux-2.5/include/linux/compiler.h
--- linux/include/linux/compiler.h Mon Sep 8 11:51:00 2003
+++ linux-2.5/include/linux/compiler.h Mon Sep 8 13:22:13 2003
@@ -74,10 +74,26 @@
#define __attribute_pure__ /* unimplemented */
#endif
+#if defined(__INTEL_COMPILER) && defined(__ECC)
+/* Optimization barrier */
+#include <asm/intrinsics.h>
+#define barrier() __memory_barrier()
+
+#define RELOC_HIDE(ptr, off) \
+ ({ unsigned long __ptr; \
+ __ptr = (unsigned long) (ptr); \
+ (typeof(ptr)) (__ptr + (off)); })
+#else
+/* Optimization barrier */
+/* The "volatile" is due to gcc bugs */
+#define barrier() asm volatile ("":::"memory")
+
/* This macro obfuscates arithmetic on a variable address so that gcc
shouldn't recognize the original var, and make assumptions about it */
#define RELOC_HIDE(ptr, off) \
({ unsigned long __ptr; \
__asm__ ("" : "=g"(__ptr) : "0"(ptr)); \
(typeof(ptr)) (__ptr + (off)); })
+#endif
+
#endif /* __LINUX_COMPILER_H */
diff -Nru linux/include/linux/kernel.h linux-2.5/include/linux/kernel.h
--- linux/include/linux/kernel.h Mon Sep 8 11:51:01 2003
+++ linux-2.5/include/linux/kernel.h Mon Sep 8 12:06:14 2003
@@ -15,10 +15,6 @@
#include <asm/byteorder.h>
#include <asm/bug.h>
-/* Optimization barrier */
-/* The "volatile" is due to gcc bugs */
-#define barrier() __asm__ __volatile__("": : :"memory")
-
#define INT_MAX ((int)(~0U>>1))
#define INT_MIN (-INT_MAX - 1)
#define UINT_MAX (~0U)
>>>>> "Suresh" == Siddha, Suresh B <[email protected]> writes:
Suresh> Intel ecc compiler doesn't support inline assembly. Attached
Suresh> patch is required to enable linux kernel build with Intel ecc
Suresh> compiler. Please apply.
Hi Suresh,
It has always been the community policy that the kernel is compiled
with GCC. Therefore wouldn't it be more appropriate to ask Intel to
fix it's compiler than changing the kernel like this?
Cheers,
Jes
On Mon, Sep 08, 2003 at 06:04:40PM -0700, Siddha, Suresh B wrote:
> Intel ecc compiler doesn't support inline assembly.
> Attached patch is required to enable linux kernel build with Intel ecc compiler.
> Please apply.
No. Currently kernel is supposed to be GNU C. Using C89/C99 constructs
instead of GCCisms is fine and a good idea where it makes code more readable
and doesn't degrade performace. Adding hacks for propritary compilers is
a very bad idea.
I can't see how you can compile the kernel with theses few changes without
inline assembly anyway..
Could you try to test your RELOC_HIDE version with various gcc versions
and maybe as some gcc gurus whether it's fine? It would defintily fall
into category (1) above. You'd need to come up with something nicer for
barrier(), though..
Thanks Jes and Christoph for your comments. As you have noticed,
this patch is not a workaround/hack for any C standard violation.
We believe that we are trying to improve the code by localizing
the compiler issues (including the ones for gcc3 and Intel complier)
and by introducing use of compiler intrinsics (e.g. for barrier()).
> Could you try to test your RELOC_HIDE version with various
> gcc versions
> and maybe as some gcc gurus whether it's fine?
RELOC_HIDE is handling a specific gcc version behaviour.
There was a discussion on this sometime back
http://gcc.gnu.org/ml/gcc/2002-01/msg00484.html
Richard Henderson mentioned that asm stmt is the only escape
hitch for the current compiler behaviour. But as Linus suggested
in the above mail thread, non-same-type cast(which is the current
solution for Intel compiler) is the way to go for gcc also.
As far as barrier() is concerned, a cleaner approach would be
a compiler-specific intrinsic(something like the one implemented by
Intel compiler) that can tell the programmer's intention explicitly.
Once gcc has a cleaner solution for both these macros, we can
do-away with these changes.
thanks,
suresh
>>>>> "Suresh" == Siddha, Suresh B <[email protected]> writes:
Suresh> We believe that we are trying to improve the code by
Suresh> localizing the compiler issues (including the ones for gcc3
Suresh> and Intel complier) and by introducing use of compiler
Suresh> intrinsics (e.g. for barrier()).
Hi Suresh,
I actually think this is degrading the code rather then improving
it. Right now the various macros are located in the include/asm-<foo>
directory next to the items where they are used. Moving it all into
one big catch-all assembly file makes it a lot harder to read things
and debug the code. I already took a look at the changes that went
into the ia64 part of the tree and I really think that was a step
backwards.
In terms of compiling the Linux kernel, I will argue that the Intel
compiler is broken if it cannot handle inline assembly. Inline
assembly is just too fundamental a feature for the kernel. This is
totally ignoring the question of whether one should be compiling the
kernel with non-GCC in the first place.
Regards,
Jes
On Tue, 9 Sep 2003, David Mosberger wrote:
>
> In my opinion, moving all the asm-stuff greatly improved readability
> of the source code. Especially for folks who are not intimately
> familiar with GCC asm syntax (which is hairy _and_ platform-specific).
I might agree, but "compiler.h" is getting increasingly messy, and this
just makes it worse (and sets the stage for making it even worse in the
future).
Is somebody willing to split up compiler.h into a per-compiler file (and
yes, I think "gcc-2.95" is a different compiler from "gcc-3.2" in this
case, since that is what most of the compiler.h #ifdef's are all about).
Then, have a config-time "set the right symbolic link" the same way we do
for "include/asm/", so that we can have a set of _clean_
compiler-dependent abstractions.
At that point, we can look at adding support for non-gcc compilers without
horrible problems. At least as long as the compiler otherwise is
"sufficiently good" (which clearly right now includes support for inline
assembly on most architectures).
Linus
>>>>> On 09 Sep 2003 15:51:05 -0400, Jes Sorensen <[email protected]> said:
Jes> I actually think this is degrading the code rather then
Jes> improving it. Right now the various macros are located in the
Jes> include/asm-<foo> directory next to the items where they are
Jes> used. Moving it all into one big catch-all assembly file makes
Jes> it a lot harder to read things and debug the code. I already
Jes> took a look at the changes that went into the ia64 part of the
Jes> tree and I really think that was a step backwards.
In my opinion, moving all the asm-stuff greatly improved readability
of the source code. Especially for folks who are not intimately
familiar with GCC asm syntax (which is hairy _and_ platform-specific).
Jes> In terms of compiling the Linux kernel, I will argue that the
Jes> Intel compiler is broken if it cannot handle inline
Jes> assembly. Inline assembly is just too fundamental a feature for
Jes> the kernel. This is totally ignoring the question of whether
Jes> one should be compiling the kernel with non-GCC in the first
Jes> place.
I think the jury is out on this one. Clearly it's a huge benefit if
you can make do without inline asm. GCC has to make lots of
worst-case assumptions whenever it encounters an asm statement and,
due to macros and inlining, the asm statements are not just hidden in
a few leaf routines. In my opinion, this experiment is at least worth
a try. If it succeeds, great, if it fails (e.g., the Intel compiler
folks fail to keep up with the kernel), all we have to do is
rm intel_intrin.h.
--david
On Tue, Sep 09, 2003 at 01:33:51PM -0700, Linus Torvalds wrote:
>
> Then, have a config-time "set the right symbolic link" the same way we do
> for "include/asm/", so that we can have a set of _clean_
> compiler-dependent abstractions.
I would prefer to have a compiler.h like this:
#if COMPILER=GCC-2.95
#include <compiler_gcc295.h
#endif
#if COMPILER=INTEL
#include <compiler_intel.h>
#endif
Better one more indirection in a simple compiler.h file than another symlink.
Symlinks should be used in rare cases only.
Sam
>>>>> On Tue, 9 Sep 2003 13:33:51 -0700 (PDT), Linus Torvalds <[email protected]> said:
Linus> I might agree, but "compiler.h" is getting increasingly
Linus> messy, and this just makes it worse (and sets the stage for
Linus> making it even worse in the future).
Linus> Is somebody willing to split up compiler.h into a
Linus> per-compiler file (and yes, I think "gcc-2.95" is a different
Linus> compiler from "gcc-3.2" in this case, since that is what most
Linus> of the compiler.h #ifdef's are all about).
How about something like this?
(the patch has Works-for-Me status...)
--david
===== include/linux/compiler.h 1.18 vs edited =====
--- 1.18/include/linux/compiler.h Thu Aug 14 18:17:28 2003
+++ edited/include/linux/compiler.h Tue Sep 9 16:28:07 2003
@@ -2,26 +2,21 @@
#define __LINUX_COMPILER_H
#ifdef __CHECKER__
- #define __user __attribute__((noderef, address_space(1)))
- #define __kernel /* default address space */
+# define __user __attribute__((noderef, address_space(1)))
+# define __kernel /* default address space */
#else
- #define __user
- #define __kernel
+# define __user
+# define __kernel
#endif
-#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
-#define inline __inline__ __attribute__((always_inline))
-#define __inline__ __inline__ __attribute__((always_inline))
-#define __inline __inline__ __attribute__((always_inline))
-#endif
-
-/* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
- a mechanism by which the user can annotate likely branch directions and
- expect the blocks to be reordered appropriately. Define __builtin_expect
- to nothing for earlier compilers. */
-
-#if __GNUC__ == 2 && __GNUC_MINOR__ < 96
-#define __builtin_expect(x, expected_value) (x)
+#if __GNUC__ > 3
+# include <linux/compiler-gcc+.h> /* catch-all for GCC 4, 5, etc. */
+#elif __GNUC__ == 3
+# include <linux/compiler-gcc3.h>
+#elif __GNUC__ == 2
+# include <linux/compiler-gcc2.h>
+#else
+# error Sorry, your compiler is too old/not recognized.
#endif
#define likely(x) __builtin_expect(!!(x), 1)
@@ -33,10 +28,8 @@
* Usage is:
* int __deprecated foo(void)
*/
-#if ( __GNUC__ == 3 && __GNUC_MINOR__ > 0 ) || __GNUC__ > 3
-#define __deprecated __attribute__((deprecated))
-#else
-#define __deprecated
+#ifndef __deprecated
+# define __deprecated /* unimplemented */
#endif
/*
@@ -50,10 +43,8 @@
* In prior versions of gcc, such functions and data would be emitted, but
* would be warned about except with attribute((unused)).
*/
-#if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || __GNUC__ > 3
-#define __attribute_used__ __attribute__((__used__))
-#else
-#define __attribute_used__ __attribute__((__unused__))
+#ifndef __attribute_used__
+# define __attribute_used__ /* unimplemented */
#endif
/*
@@ -65,19 +56,9 @@
* elimination and loop optimization just as an arithmetic operator
* would be.
* [...]
- * The attribute `pure' is not implemented in GCC versions earlier
- * than 2.96.
*/
-#if (__GNUC__ == 2 && __GNUC_MINOR__ >= 96) || __GNUC__ > 2
-#define __attribute_pure__ __attribute__((pure))
-#else
-#define __attribute_pure__ /* unimplemented */
+#ifndef __attribute_pure__
+# define __attribute_pure__ /* unimplemented */
#endif
-/* This macro obfuscates arithmetic on a variable address so that gcc
- shouldn't recognize the original var, and make assumptions about it */
-#define RELOC_HIDE(ptr, off) \
- ({ unsigned long __ptr; \
- __asm__ ("" : "=g"(__ptr) : "0"(ptr)); \
- (typeof(ptr)) (__ptr + (off)); })
#endif /* __LINUX_COMPILER_H */
--- /dev/null 2003-03-27 10:58:26.000000000 -0800
+++ include/linux/compiler-gcc+.h 2003-09-09 16:39:42.000000000 -0700
@@ -0,0 +1,13 @@
+/* Never include this file directly. Include <linux/compiler.h> instead. */
+
+/*
+ * These definitions are for Ueber-GCC: always newer than the latest
+ * version and hence sporting everything plus a kitchen-sink.
+ */
+
+#define inline __inline__ __attribute__((always_inline))
+#define __inline__ __inline__ __attribute__((always_inline))
+#define __inline __inline__ __attribute__((always_inline))
+#define __deprecated __attribute__((deprecated))
+#define __attribute_used__ __attribute__((__used__))
+#define __attribute_pure__ __attribute__((pure))
--- /dev/null 2003-03-27 10:58:26.000000000 -0800
+++ include/linux/compiler-gcc3.h 2003-09-09 16:40:11.000000000 -0700
@@ -0,0 +1,21 @@
+/* Never include this file directly. Include <linux/compiler.h> instead. */
+
+/* These definitions are for GCC v3.x. */
+
+#if __GNUC_MINOR__ >= 1
+# define inline __inline__ __attribute__((always_inline))
+# define __inline__ __inline__ __attribute__((always_inline))
+# define __inline __inline__ __attribute__((always_inline))
+#endif
+
+#if __GNUC_MINOR__ > 0
+# define __deprecated __attribute__((deprecated))
+#endif
+
+#if __GNUC_MINOR__ >= 3
+# define __attribute_used__ __attribute__((__used__))
+#else
+# define __attribute_used__ __attribute__((__unused__))
+#endif
+
+#define __attribute_pure__ __attribute__((pure))
--- /dev/null 2003-03-27 10:58:26.000000000 -0800
+++ include/linux/compiler-gcc2.h 2003-09-09 16:40:06.000000000 -0700
@@ -0,0 +1,22 @@
+/* Never include this file directly. Include <linux/compiler.h> instead. */
+
+/* These definitions are for GCC v2.x. */
+
+/* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
+ a mechanism by which the user can annotate likely branch directions and
+ expect the blocks to be reordered appropriately. Define __builtin_expect
+ to nothing for earlier compilers. */
+
+#if __GNUC_MINOR__ < 96
+# define __builtin_expect(x, expected_value) (x)
+#endif
+
+#define __attribute_used__ __attribute__((__unused__))
+
+/*
+ * The attribute `pure' is not implemented in GCC versions earlier
+ * than 2.96.
+ */
+#if __GNUC_MINOR__ >= 96
+# define __attribute_pure__ __attribute__((pure))
+#endif
> How about something like this?
> (the patch has Works-for-Me status...)
>
> --david
Attached the patch with minor changes to David's patch.
include/linux/compiler.h defines the generic
definitions which are overwritten by per-compiler definitions.
include/linux/compiler-gcc.h contains the common definitions
for all gcc versions.
include/linux/compiler-gcc[2,3,+].h contains gcc version
specific definitions.
And intel.diff patch adds Intel compiler specific definitions.
thanks,
suresh
diff -Nru linux/include/linux/compiler-gcc+.h linux-/include/linux/compiler-gcc+.h
--- linux/include/linux/compiler-gcc+.h Wed Dec 31 16:00:00 1969
+++ linux-/include/linux/compiler-gcc+.h Tue Sep 9 21:26:03 2003
@@ -0,0 +1,14 @@
+/* Never include this file directly. Include <linux/compiler.h> instead. */
+
+/*
+ * These definitions are for Ueber-GCC: always newer than the latest
+ * version and hence sporting everything plus a kitchen-sink.
+ */
+#include <linux/compiler-gcc.h>
+
+#define inline __inline__ __attribute__((always_inline))
+#define __inline__ __inline__ __attribute__((always_inline))
+#define __inline __inline__ __attribute__((always_inline))
+#define __deprecated __attribute__((deprecated))
+#define __attribute_used__ __attribute__((__used__))
+#define __attribute_pure__ __attribute__((pure))
diff -Nru linux/include/linux/compiler-gcc.h linux-/include/linux/compiler-gcc.h
--- linux/include/linux/compiler-gcc.h Wed Dec 31 16:00:00 1969
+++ linux-/include/linux/compiler-gcc.h Tue Sep 9 21:26:03 2003
@@ -0,0 +1,17 @@
+/* Never include this file directly. Include <linux/compiler.h> instead. */
+
+/*
+ * Common definitions for all gcc versions go here.
+ */
+
+
+/* Optimization barrier */
+/* The "volatile" is due to gcc bugs */
+#define barrier() __asm__ __volatile__("": : :"memory")
+
+/* This macro obfuscates arithmetic on a variable address so that gcc
+ shouldn't recognize the original var, and make assumptions about it */
+#define RELOC_HIDE(ptr, off) \
+ ({ unsigned long __ptr; \
+ __asm__ ("" : "=g"(__ptr) : "0"(ptr)); \
+ (typeof(ptr)) (__ptr + (off)); })
diff -Nru linux/include/linux/compiler-gcc2.h linux-/include/linux/compiler-gcc2.h
--- linux/include/linux/compiler-gcc2.h Wed Dec 31 16:00:00 1969
+++ linux-/include/linux/compiler-gcc2.h Tue Sep 9 21:26:03 2003
@@ -0,0 +1,23 @@
+/* Never include this file directly. Include <linux/compiler.h> instead. */
+
+/* These definitions are for GCC v2.x. */
+
+/* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
+ a mechanism by which the user can annotate likely branch directions and
+ expect the blocks to be reordered appropriately. Define __builtin_expect
+ to nothing for earlier compilers. */
+#include <linux/compiler-gcc.h>
+
+#if __GNUC_MINOR__ < 96
+# define __builtin_expect(x, expected_value) (x)
+#endif
+
+#define __attribute_used__ __attribute__((__unused__))
+
+/*
+ * The attribute `pure' is not implemented in GCC versions earlier
+ * than 2.96.
+ */
+#if __GNUC_MINOR__ >= 96
+# define __attribute_pure__ __attribute__((pure))
+#endif
diff -Nru linux/include/linux/compiler-gcc3.h linux-/include/linux/compiler-gcc3.h
--- linux/include/linux/compiler-gcc3.h Wed Dec 31 16:00:00 1969
+++ linux-/include/linux/compiler-gcc3.h Tue Sep 9 21:26:03 2003
@@ -0,0 +1,22 @@
+/* Never include this file directly. Include <linux/compiler.h> instead. */
+
+/* These definitions are for GCC v3.x. */
+#include <linux/compiler-gcc.h>
+
+#if __GNUC_MINOR__ >= 1
+# define inline __inline__ __attribute__((always_inline))
+# define __inline__ __inline__ __attribute__((always_inline))
+# define __inline __inline__ __attribute__((always_inline))
+#endif
+
+#if __GNUC_MINOR__ > 0
+# define __deprecated __attribute__((deprecated))
+#endif
+
+#if __GNUC_MINOR__ >= 3
+# define __attribute_used__ __attribute__((__used__))
+#else
+# define __attribute_used__ __attribute__((__unused__))
+#endif
+
+#define __attribute_pure__ __attribute__((pure))
diff -Nru linux/include/linux/compiler.h linux-/include/linux/compiler.h
--- linux/include/linux/compiler.h Mon Sep 8 11:51:00 2003
+++ linux-/include/linux/compiler.h Tue Sep 9 21:32:44 2003
@@ -2,28 +2,28 @@
#define __LINUX_COMPILER_H
#ifdef __CHECKER__
- #define __user __attribute__((noderef, address_space(1)))
- #define __kernel /* default address space */
+# define __user __attribute__((noderef, address_space(1)))
+# define __kernel /* default address space */
#else
- #define __user
- #define __kernel
+# define __user
+# define __kernel
#endif
-#if (__GNUC__ > 3) || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)
-#define inline __inline__ __attribute__((always_inline))
-#define __inline__ __inline__ __attribute__((always_inline))
-#define __inline __inline__ __attribute__((always_inline))
-#endif
-
-/* Somewhere in the middle of the GCC 2.96 development cycle, we implemented
- a mechanism by which the user can annotate likely branch directions and
- expect the blocks to be reordered appropriately. Define __builtin_expect
- to nothing for earlier compilers. */
-
-#if __GNUC__ == 2 && __GNUC_MINOR__ < 96
-#define __builtin_expect(x, expected_value) (x)
+#if __GNUC__ > 3
+# include <linux/compiler-gcc+.h> /* catch-all for GCC 4, 5, etc. */
+#elif __GNUC__ == 3
+# include <linux/compiler-gcc3.h>
+#elif __GNUC__ == 2
+# include <linux/compiler-gcc2.h>
+#else
+# error Sorry, your compiler is too old/not recognized.
#endif
+/*
+ * Below are the generic compiler related macros required for kernel
+ * build. Actual compiler/compiler version specific implementations
+ * come from the above header files
+ */
#define likely(x) __builtin_expect(!!(x), 1)
#define unlikely(x) __builtin_expect(!!(x), 0)
@@ -33,10 +33,8 @@
* Usage is:
* int __deprecated foo(void)
*/
-#if ( __GNUC__ == 3 && __GNUC_MINOR__ > 0 ) || __GNUC__ > 3
-#define __deprecated __attribute__((deprecated))
-#else
-#define __deprecated
+#ifndef __deprecated
+# define __deprecated /* unimplemented */
#endif
/*
@@ -50,10 +48,8 @@
* In prior versions of gcc, such functions and data would be emitted, but
* would be warned about except with attribute((unused)).
*/
-#if __GNUC__ == 3 && __GNUC_MINOR__ >= 3 || __GNUC__ > 3
-#define __attribute_used__ __attribute__((__used__))
-#else
-#define __attribute_used__ __attribute__((__unused__))
+#ifndef __attribute_used__
+# define __attribute_used__ /* unimplemented */
#endif
/*
@@ -65,19 +61,21 @@
* elimination and loop optimization just as an arithmetic operator
* would be.
* [...]
- * The attribute `pure' is not implemented in GCC versions earlier
- * than 2.96.
*/
-#if (__GNUC__ == 2 && __GNUC_MINOR__ >= 96) || __GNUC__ > 2
-#define __attribute_pure__ __attribute__((pure))
-#else
-#define __attribute_pure__ /* unimplemented */
+#ifndef __attribute_pure__
+# define __attribute_pure__ /* unimplemented */
+#endif
+
+/* Optimization barrier */
+#ifndef barrier
+# define barrier() __memory_barrier();
#endif
-/* This macro obfuscates arithmetic on a variable address so that gcc
- shouldn't recognize the original var, and make assumptions about it */
-#define RELOC_HIDE(ptr, off) \
+#ifndef RELOC_HIDE
+# define RELOC_HIDE(ptr, off) \
({ unsigned long __ptr; \
- __asm__ ("" : "=g"(__ptr) : "0"(ptr)); \
+ __ptr = (unsigned long) (ptr); \
(typeof(ptr)) (__ptr + (off)); })
+#endif
+
#endif /* __LINUX_COMPILER_H */
diff -Nru linux/include/linux/kernel.h linux-/include/linux/kernel.h
--- linux/include/linux/kernel.h Mon Sep 8 11:51:01 2003
+++ linux-/include/linux/kernel.h Tue Sep 9 21:26:03 2003
@@ -15,10 +15,6 @@
#include <asm/byteorder.h>
#include <asm/bug.h>
-/* Optimization barrier */
-/* The "volatile" is due to gcc bugs */
-#define barrier() __asm__ __volatile__("": : :"memory")
-
#define INT_MAX ((int)(~0U>>1))
#define INT_MIN (-INT_MAX - 1)
#define UINT_MAX (~0U)
diff -Nru linux/include/linux/compiler-intel.h linux-/include/linux/compiler-intel.h
--- linux/include/linux/compiler-intel.h Wed Dec 31 16:00:00 1969
+++ linux-/include/linux/compiler-intel.h Tue Sep 9 21:34:19 2003
@@ -0,0 +1,21 @@
+/* Never include this file directly. Include <linux/compiler.h> instead. */
+
+#ifdef __ECC
+
+/* Some compiler specific definitions are overwritten here
+ * for Intel ECC compiler
+ */
+
+#include <asm/intrinsics.h>
+
+#undef barrier
+#undef RELOC_HIDE
+
+#define barrier() __memory_barrier()
+
+#define RELOC_HIDE(ptr, off) \
+ ({ unsigned long __ptr; \
+ __ptr = (unsigned long) (ptr); \
+ (typeof(ptr)) (__ptr + (off)); })
+
+#endif
diff -Nru linux/include/linux/compiler.h linux-/include/linux/compiler.h
--- linux/include/linux/compiler.h Tue Sep 9 21:34:11 2003
+++ linux-/include/linux/compiler.h Tue Sep 9 21:35:08 2003
@@ -19,6 +19,13 @@
# error Sorry, your compiler is too old/not recognized.
#endif
+/* Intel compiler defines __GNUC__. So we will overwrite implementations
+ * coming from above header files here
+ */
+#ifdef __INTEL_COMPILER
+# include <linux/compiler-intel.h>
+#endif
+
/*
* Below are the generic compiler related macros required for kernel
* build. Actual compiler/compiler version specific implementations
"Siddha, Suresh B" <[email protected]> wrote:
>
> --- linux/include/linux/compiler-intel.h Wed Dec 31 16:00:00 1969
> +++ linux-/include/linux/compiler-intel.h Tue Sep 9 21:34:19 2003
> @@ -0,0 +1,21 @@
> +/* Never include this file directly. Include <linux/compiler.h> instead. */
> +
> +#ifdef __ECC
> +
> +/* Some compiler specific definitions are overwritten here
> + * for Intel ECC compiler
> + */
> +
> +#include <asm/intrinsics.h>
This is ia64-only, yes?
Where do we stand with ECC/ia32 support?
Yes, ECC is only for IA-64. ICC is for x86. ICC does not require
intrinsics because it supports asm inline, and it can build the kernel.
Please look at
http://lists.insecure.org/lists/linux-kernel/2002/Oct/8790.html for
example.
Note that asm inline support is just one of many GCC extensions required
to build the kernel, and for optimization purposes Intel compiler for
IA-64 chose not to support inline asm, but it uses intrinsic to do the
equivalent things.
Thanks,
Jun
> -----Original Message-----
> From: Andrew Morton [mailto:[email protected]]
> Sent: Tuesday, September 09, 2003 10:08 PM
> To: Siddha, Suresh B
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; Nakajima, Jun;
Mallick,
> Asit K
> Subject: Re: [Patch] asm workarounds in generic header files
>
> "Siddha, Suresh B" <[email protected]> wrote:
> >
> > --- linux/include/linux/compiler-intel.h Wed Dec 31 16:00:00 1969
> > +++ linux-/include/linux/compiler-intel.h Tue Sep 9 21:34:19 2003
> > @@ -0,0 +1,21 @@
> > +/* Never include this file directly. Include <linux/compiler.h>
> instead. */
> > +
> > +#ifdef __ECC
> > +
> > +/* Some compiler specific definitions are overwritten here
> > + * for Intel ECC compiler
> > + */
> > +
> > +#include <asm/intrinsics.h>
>
> This is ia64-only, yes?
>
> Where do we stand with ECC/ia32 support?
>>>>> "David" == David Mosberger <[email protected]> writes:
[trimmed the CC list since this is more at the preference level]
David> In my opinion, moving all the asm-stuff greatly improved
David> readability of the source code. Especially for folks who are
David> not intimately familiar with GCC asm syntax (which is hairy
David> _and_ platform-specific).
Hi David,
I think this really depends on what you are trying to debug. If you
expect the macros to do exactly what they are described to be doing
then I'd agree. However every so often when you look up the macros you
really want to look at the details what they are actually doing or
even compare them to another arch's implementation to make sure they
are behaving the same. At least thats my experience.
I personally think it's unrealistic to think one can try and debug
things in include/asm without being able to read the assembly output
in the first place.
David> I think the jury is out on this one. Clearly it's a huge
David> benefit if you can make do without inline asm. GCC has to make
David> lots of worst-case assumptions whenever it encounters an asm
David> statement and, due to macros and inlining, the asm statements
David> are not just hidden in a few leaf routines.
Reducing the amount of inline asm in the kernel would be a good
thing. It is cetainly one of those things that have been abused way
beyond it's intent.
Cheers,
Jes
>>>>> On 10 Sep 2003 12:22:37 -0400, Jes Sorensen <[email protected]> said:
Jes> I think this really depends on what you are trying to debug. If
Jes> you expect the macros to do exactly what they are described to
Jes> be doing then I'd agree. However every so often when you look
Jes> up the macros you really want to look at the details what they
Jes> are actually doing or even compare them to another arch's
Jes> implementation to make sure they are behaving the same. At
Jes> least thats my experience.
That's true for some, but not others. For example, I'd say that
things like getreg() and setreg() are pretty intuitive.
Jes> I personally think it's unrealistic to think one can try and
Jes> debug things in include/asm without being able to read the
Jes> assembly output in the first place.
Assembly output != GCC asm statements. There are lots of
assembly-savy folks that have no clue how to read/interpret the GCC
asm syntax. Those folks have the option of either generating an
assembly file or disassembling the resulting object file. Both
approaches would let them read the resulting code without having to
know exactly how the asm statement (or intrinsic) works.
David> I think the jury is out on this one. Clearly it's a huge
David> benefit if you can make do without inline asm. GCC has to
David> make lots of worst-case assumptions whenever it encounters an
David> asm statement and, due to macros and inlining, the asm
David> statements are not just hidden in a few leaf routines.
Jes> Reducing the amount of inline asm in the kernel would be a good
Jes> thing. It is cetainly one of those things that have been abused
Jes> way beyond it's intent.
Agreed.
--david