This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Type of alarm-function
- From: Thomas KlÃber <thomas at kdut dot de>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Wed, 5 Mar 2008 13:52:16 +0100
- Subject: [ECOS] Type of alarm-function
Hello all,
I am porting eCos to the Infineon TriCore TC1796 as part of my studies. I am
using the kernel testcases to verify it's working, most ones are running just
fine. During stepping throug kclock0.c as it wouldn't work, I found the
following:
The prototype for an alarm handler function in the C kernel api is
void alarm_handler(cyg_handle_t alarm, cyg_addrword_t data)
with cyg_handle_t being a cyg_uint32. The internal kernel prototype for
calling the function however is
void cyg_alarm_fn(Cyg_Alarm *alarm, CYG_ADDRWORD data)
Note that the first argument is a pointer in this case. While on most
architectures this does not make any difference, it circumvents passing of
parameters to the function.
The TC1796 has separate registers for addresses and for data which are used
for passing parameters. When calling a function of type cyg_alarm_fn, the
compiler puts the first argument into an address register (%a4) and the
second one into a data register (%d4). Unfortunately, the called function has
the type alarm_handler, so the compiler trys to read both values from data
registers (%d4 and %d5) when entering the function.
The result is that neither of the arguments is passed correctly to the
function as the first one lies in %a4 instead of %d4 and the second one lies
in %d4 instead of %d5.
imho one of the prototypes for the function should be corrected to guarantee
correct behaviour on all platforms.
Any opinions on this?
Tom
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss