[ECOS] Cannot Build eCos Common HAL with PowerPC Altivec Instructions

[Gary Thomas]

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
------------------------------------------------------------
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <http://sourceware.org/pipermail/ecos-discuss/attachments/20070627/1317ae36/attachment.ksh>
-------------- next part --------------
-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss