This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]