RE: [sv-cc] question about mapping of types in DPI

Hi Francoise,

The main reason for the mapping, in my opinion, is that this
mapping gives C programmers a convenient way to make use of
the standard C types "char" and "short". Unsigned vs. signed
is somewhat secondary compared to the alignment considerations
presented by mapping a C "char" to a SV "byte" (similar for short).

If we didn't have this mapping, what would it even mean for a
C programmer to use a "char" at the language boundary? It would
basically be unsupportable. We'd force C programmers to make use
of the somewhat unwieldy svBitVec32 and its API, rather than
allow "direct" programming with native datatypes.

Regarding the flexibility of C and ANSI-C, I agree that is an
issue that could use clarification. We've tested a wide variety
of C/C++ compilers on a wide variety of platforms. (Native cc + gcc
ON Solaris, Linux, HPUX, AIX, WinXP WITH 32-bit and 64-bit modes).
By default they all make use of the LP64 model in 64-bit mode and
the ILP32 model in 32-bit mode.

We might be able to improve the LRM with a statement specifying that
the standard LP64 model is used for 64-bit compilation and the
standard ILP32 model is used for 32-bit compilation.

We should also consider stating that non-standard alignment flags
such as gcc's -malign-double should not be used when compiling
DPI C code. Though this may be getting into the implementation
space rather than the standards space.

Regards,
Doug

> -----Original Message-----
> From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
> Behalf Of Francoise Martinolle
> Sent: Monday, September 20, 2004 10:48 AM
> To: sv-cc@eda.org
> Subject: [sv-cc] question about mapping of types in DPI
>
> I am working on resolving errata 51 which was assigned to BC.
> Jim Vellenga
> reported some
> conflicts in the LRM between the language definition and the
> DPI section.
>
> First my question is why do we map input function arguments
> of type byte
> unsigned or shortint unsigned to unsigned char C type and
> unsigned short C
> type?
> Why not mapping them to svBitVec32 is that for capacity
> reason to use the
> smallest C type available?
> Secondly the C language does not specify the exact width of
> char, short,
> int or long. For example, int may be represented in 16 or 32
> bits, long
> should be at least 32 bits. char is usually 8 bits but on a
> few computers,
> it may be 9 or 7 bits. How do we deal with this flexibility of the C
> language and ANSI-C specification ? Our table in section
> E.6.4 is assuming
> typical C implementations of int implemented with 32 bits and
> char with 8
> bits, it seems that this mapping may not always work.
>
> Francoise
> '
>
>
>
>
>
>
>
Received on Mon Sep 20 12:19:40 2004