Subject: RE: SV-CC Minutes 12/11/02
From: Amouroux, John (john_amouroux@mentorg.com)
Date: Wed Dec 11 2002 - 13:49:28 PST
Andrzej,
From today's minutes:
> Doug: Could this handle-based API also be used for
> arrays of known dimension? (For consistency of
> programming model when there is a mix of the two
> types of arguments)
>
> Andrzej: There are differences between standalone array arguments and
> arrays inside of struct arguments.
> [Doug: Sorry - I got lost and couldn't follow this
> further when typing the minutes]
I didn't quite follow your answer either. I was thinking (at least for
stand-alone array arguments) that SV could always create an array info
struct and pass a pointer to that to the C function along with the array
pointer in the argument list. This struct would be created for both sized
and unsized arrays, so that the called C function wouldn't know (or care!)
what style of array got passed in. The struct could be something simple
like this:
typedef struct svc_array_info {
unsigned size; // the number of elements
int startIndex; // the array's left bound
int endIndex; // the array's right bound
} svc_array_info_type;
But now that I've stated all this, if one did have arrays inside of structs
as you mentioned, then this array info scheme would prevent the layout of SV
structs to directly map to C structs in these cases, thus incurring a
copy-in/copy-out performance penalty. I'm guessing that something similar
to this problem is what you were talking about in your objection noted in
the minutes.
The bottom line is that a C model developer would likely prefer to not have
to worry about sized vs. unsized array types if possible (or even between
differing sized arrays), as this can minimize the amount of code they need
to develop and test. It would also make things easier for the SV developer
as they could have fewer C function names to remember and use. So I think
that anything we can do to help in this situation will be worthwhile.
-- John A.
This archive was generated by hypermail 2b28 : Wed Dec 11 2002 - 13:52:35 PST