This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Cannot Build eCos Common HAL with PowerPC Altivec Instructions
- From: Gary Thomas <gary at mlbassoc dot com>
- To: Mike Arthur <arth2219 at gmail dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Tue, 26 Jun 2007 19:52:24 -0600
- Subject: Re: [ECOS] Cannot Build eCos Common HAL with PowerPC Altivec Instructions
- References: <2a3305fe0706261607j74263c0bl3997d66e55798aed@mail.gmail.com>
Mike Arthur wrote:
> Are there any PowerPC developers using Altivec instructions with eCos ?
>
> I have a couple of MPC74xx HALs that I'd like to build with gcc's
> -maltivec flag to enable the Altivec instruction set. Any version of
> gcc above 3.4.4 (that I've tried), results in an error with the inline
> functions in hal_if.h from the Common HAL:
>
> powerpc-eabi-gcc -c -I/tmp/untitled6_install/include
> -I/opt/ecos/ecos-current/packages/hal/common/current
> -I/opt/ecos/ecos-current/packages/hal/common/current/src
> -I/opt/ecos/ecos-current/packages/hal/common/current/tests -I.
> -I/opt/ecos/ecos-current/packages/hal/common/current/src/
> -finline-limit=7000 -mcpu=604 -Wall -Wpointer-arith
> -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections
> -fdata-sections -fno-exceptions -maltivec -Wp,-MD,src/hal_if.tmp -o
> src/hal_common_hal_if.o
> /opt/ecos/ecos-current/packages/hal/common/current/src/hal_if.c
> powerpc-eabi-gcc -c -I/tmp/untitled6_install/include
> -I/opt/ecos/ecos-current/packages/hal/common/current
> -I/opt/ecos/ecos-current/packages/hal/common/current/src
> -I/opt/ecos/ecos-current/packages/hal/common/current/tests -I.
> -I/opt/ecos/ecos-current/packages/hal/common/current/src/
> -finline-limit=7000 -mcpu=604 -Wall -Wpointer-arith
> -Wstrict-prototypes -Winline -Wundef -g -O2 -ffunction-sections
> -fdata-sections -fno-exceptions -maltivec -Wp,-MD,src/hal_misc.tmp
> -o src/hal_common_hal_misc.o
> /opt/ecos/ecos-current/packages/hal/common/current/src/hal_misc.c
> In file included from
> /opt/ecos/ecos-current/packages/hal/common/current/src/hal_misc.c:57:
> /tmp/untitled6_install/include/cyg/hal/hal_if.h: In function
> `__call_COMM_IF_DBG_ISR':
> /tmp/untitled6_install/include/cyg/hal/hal_if.h:329: error:
> incompatible type for argument 3 of indirect function call
> In file included from
> /opt/ecos/ecos-current/packages/hal/common/current/src/hal_if.c:65:
> /tmp/untitled6_install/include/cyg/hal/hal_if.h: In function
> `__call_COMM_IF_DBG_ISR':
> /tmp/untitled6_install/include/cyg/hal/hal_if.h:329: error:
> incompatible type for argument 3 of indirect function call
> make[1]: Leaving directory `/tmp/untitled6_build/hal/common/current'
>
>
> The above example is building the AdderII (A&M Adder PPC852T board)
> with the "-maltivec" and "-mcpu=7450" compile flags against eCos
> current. I know that the AdderII does not support the Altivec
> instruction set, but that doesn't matter for my example. I run into
> the same problem with my MPC74XX HALs, when I compile with -maltivec.
> I just wanted to create an example that anyone with a PowerPC gcc
> compiler could duplicate.
>
> I receive the above error with powerpc-eabi-gcc 3.4.4, 3.4.6, and
> 4.1.2. I did not receive the error with powerpc-eabi-gcc 3.2.1.
>
> I believe the error stems from the
> __call_COMM3(_n_,_rt_,_t_,_t1_,_t2_,_t3_) macro. I think gcc gets
> confused with _p1_, _p2, _p3_:
>
> static __inline__ _rt_ \
> __call_COMM_##_n_(hal_virtual_comm_table_t t, _t1_ _p1_, _t2_ _p2_,
> _t3_ _p3_) \
> { \
> _rt_ res; \
> void *dp = (__comm_if_ch_data_t)t[CYGNUM_COMM_IF_CH_DATA]; \
> _ENTER_MONITOR(); \
> res = ((_t_)(t[CYGNUM_COMM_##_n_]))(dp, _p1_, _p2_,
> _p3_); \
> _EXIT_MONITOR(); \
> return res; \
> }
>
> Does anyone know of a fix for this problem?
It seems that the definition of __comm_if_dbg_isr_t is causing the
consternation. Looking at the preprocessed code (output from -E),
this line:
typedef int (*__comm_if_dbg_isr_t)(void *__ch_data,
int* __ctrlc, CYG_ADDRWORD __vector,
CYG_ADDRWORD __data);
gets turned into:
typedef int (*__comm_if_dbg_isr_t)(void *__ch_data,
int* __ctrlc, CYG_ADDRWORD __attribute__((altivec(vector__))),
CYG_ADDRWORD __data);
The attached patch (already committed) will fix it for you.
BTW - what do you need altivec instructions in the kernel for? I
can understand their use in user code, but I'm not sure about the
kernel itself.
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
Index: hal/common/current/include/hal_if.h
===================================================================
RCS file: /misc/cvsfiles/ecos/packages/hal/common/current/include/hal_if.h,v
retrieving revision 1.25
diff -u -5 -p -r1.25 hal_if.h
--- hal/common/current/include/hal_if.h 9 May 2006 15:51:39 -0000 1.25
+++ hal/common/current/include/hal_if.h 27 Jun 2007 01:50:11 -0000
@@ -189,11 +189,11 @@ typedef int (*__comm_if_read_t)(void* __
typedef void (*__comm_if_putc_t)(void* __ch_data, cyg_uint8 __ch);
typedef cyg_uint8 (*__comm_if_getc_t)(void* __ch_data);
typedef int (*__comm_if_control_t)(void *__ch_data,
__comm_control_cmd_t __func, ...);
typedef int (*__comm_if_dbg_isr_t)(void *__ch_data,
- int* __ctrlc, CYG_ADDRWORD __vector,
+ int* __ctrlc, CYG_ADDRWORD __vec,
CYG_ADDRWORD __data);
typedef cyg_bool (*__comm_if_getc_timeout_t)(void* __ch_data, cyg_uint8* __ch);
#define __call_COMM0(_n_,_rt_,_t_) \
static __inline__ _rt_ \
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss