Re: updated headers - SceMiRecoverableError revoked, please super ceed

From: Stickley, John <john_stickley@mentorg.com>
Date: Tue Aug 31 2004 - 14:59:11 PDT

Per,

Bojsen, Per wrote:
> Hi John,
>
> just a quick note as I skim through your response. I'll read it
> more carefully later.
>
>
>>I changed all the callback typedefs in the C++ header to have
>>extern "C" linkage. The static member function should not be
>>an issue because you can always more or less acheive the same
>>effect by making an ANSI C linkage function a friend of a C++
>>class. This is quite a common use model with SCE-MI applications.
>
>
> Ok, this is what we decided at the meeting and I agree with your
> concerns about interoperability with C code. However, this gives
> you another action :-) The Routed demo example uses static
> member functions for the callbacks so it should be changed as
> per your suggestion to use non-member functions that are declared
> friends of the classes they are associated with (SystemC modules
> in this case).

johnS:
Yes, I agree this should be changed.

The following corrections are required (referring to scemi-104.pdf):

---------------------------------------------
document p. 85 (section A.2.4.6) Change this:

static void replyCallback( void *context, const SceMiMessageData *data );

To this:

friend void replyCallback( void *context, const SceMiMessageData *data );

---------------------------------------------
document p. 88 (section A.2.4.6.3) Change this:

void Scheduler::replyCallback( void *context, const SceMiMessageData *data ){
((Scheduler *)context)->announceArrival( data->CycleStamp(),
data->Get(0) ); }

To this:

extern "C" {
void replyCallback( void *context, const SceMiMessageData *data ){
((Scheduler *)context)->announceArrival( data->CycleStamp(),
data->Get(0) ); }
};

>
>
>>On a related note I changed the 'bool pending' arg of the g
>>function typedef to 'int pending' instead. This removes
>>dependency on the "to bool or not to bool' quirck between
>>ANSI C and C++. In otherwords, since C++ define bool but
>>ANSI C doesn't, let's make our life easier by removing this
>>dependency entirely.
>
>
> Didn't C99 introduce bool? Have we stated somewhere which version(s)
> of ANSI-C and C++ we want to be compatible with? I assume we are
> aiming for the largest audience, i.e., lowest common denominator?
>
> Per
>

johnS:
You might be right here. I'm a little rusty on what is supported
in ANSI C and what is not. I'm open to keeping bool if it is supported
in ANSI C and also to stating that the spec conforms to C99.

Or to lowest common denominator by make it an int. What do
you think ?

-- johnS

______________________________/\/ \ \
John Stickley \ \ \
Principal Engineer \ \________________
Mentor Graphics - MED \_
17 E. Cedar Place \ john_stickley@mentor.com
Ramsey, NJ 07446 \ Phone: (201) 818-2585
________________________________________________________________
Received on Tue Aug 31 15:02:44 2004

This archive was generated by hypermail 2.1.8 : Tue Aug 31 2004 - 15:04:00 PDT