System/Verilog C/C++ Committee: Re: [sv-cc] Item 205: 64-bit con

From: Andrzej I. Litwiniuk <Andrzej.Litwiniuk@synopsys.com>
Date: Wed Nov 03 2004 - 09:35:52 PST

> On closer inspection, I do not believe that the prevalence of "64-bit
> machines"=20
> would pose any unique difficulties for binary-compatible packed types
> based on=20
> 32-bit chunks. =20

Ralph,

I've never claimed that 32-bit C integer type would disappear.
The message that I apparently failed to convey was that the abundance
of 64-bit machines may lead vendors to use heterogenous representation
of packed arrays with different sizes of 'chunks" depeneding on the size,
specifically, that long packed arrays may be represented using 64-bit chunks.
And 64-bit value usually require 8-byte alignment.
That's why we must not specify that every packed array shall be represented
as an array of 32-bit chunks.
Leaving this open allows both for smaller chunks (1-byte) and longer chunks
(64-bit), in addition to 32-bit chunks.
And I don't see any conflict with that fact that small vectors passed
=by value= will use 32-bit integers. 5-bit packed array may be internally
represented as a byte, or a short int or int, or whatever, and still be
passed as C int without any overhead.

Thanks,

Andrzej

> Here are three reasons.=20
>
> a. Even pervasive use of '64-bit machines' is very unlikely to make C
> compiler vendors=20
> change the size of 'unsigned int' to 64-bits. They might make 'long'
> and 'long long' consume=20
> 64-bits on more platforms. However, changing the size of 'int' to 64
> bits would render=20
> many thousands of C programs obsolete. This is unlikely.=20
>
> b. Most important is that Item 205 intends to tie the vendor chunk size
> to the canonical chunk size=20
> (which happens to be 32 bits). The match between unsigned ints and
> 32-bits already exists in the LRM.=20
> . Each canonical chunk is defined in terms of unsigned int (E.9.1.2,
> F.1) and the LRM =20
> expects it to be "representing 32 bits" (E.6.7). =20
> . Similarly, we also have 2-state values <=3D 32 bits passed by =
> value
> in unsigned ints (E.7.7). =20
>
> Thus, the LRM expects C unsigned ints to be 32-bit entities. This
> is not specific to Item-205.=20
> =20
> c. Various suggestions are already in the works to tie the size of our
> canonical forms and =20
> proposed forms to definitions such as uint32_t or something like it.
> Given the extreme =20
> unlikelihood of all 32-bit C integer types disappearing, this should
> provide a sound basis for =20
> specifying the size of embedded packed types. =20
>
> Summary: The disappearance of a 32-bit C integer types is extremely
> unlikely. Regardless of 205's fate we =20
> already have 32-bit values tied to unsigned ints. We are also already
> at work (separately) on a robust way =20
> of indicating C data type sizes.=20
>
> Ralph Duncan
> Mentor Graphics
>
> ------_=_NextPart_001_01C4C1BE.5F5D1349
> Content-Type: text/html;
> charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
>
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
> <HTML>
> <HEAD>
> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
> charset=3Dus-ascii">
> <META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
> 6.5.7226.0">
> <TITLE>Item 205: 64-bit concerns</TITLE>
> </HEAD>
> <BODY>
> 
>
> On closer inspection, I do not believe =
> that the prevalence of  "64-bit machines" 
>
> would pose any unique difficulties for =
> binary-compatible packed types based on 
>
> 32-bit chunks.  
> 
>
> Here are three reasons. 
> 
>
> a. Even pervasive use of '64-bit =
> machines' is very unlikely to make C compiler vendors 
>
>    change the size of =
> 'unsigned int' to 64-bits.  They might make 'long' and 'long long' =
> consume 
>
>    64-bits on more =
> platforms.  However, changing the size of 'int' to 64 bits would =
> render 
>
>    many thousands of C =
> programs obsolete.  This is unlikely. 
> 
>
> b. Most important is that Item 205 =
> intends to tie the vendor chunk size to the canonical chunk size 
>
>     (which happens to =
> be 32 bits).  The match between unsigned ints and 32-bits already =
> exists in the LRM. 
>
>     . Each canonical =
> chunk is defined in terms of unsigned int (E.9.1.2, F.1) and the =
> LRM  
>
>       expects =
> it to be "representing 32 bits" (E.6.7).   
>
>     . Similarly, we =
> also have 2-state values <=3D 32 bits passed by value in unsigned =
> ints (E.7.7).  
> 
>
>     Thus, the LRM =
> expects C unsigned ints to be 32-bit entities.  This is not =
> specific to Item-205. 
>
>     
>
> c. Various suggestions are already in =
> the works to tie the size of our canonical forms and  
>
>     proposed forms to =
> definitions such as uint32_t or something like it.  Given the =
> extreme  
>
>     unlikelihood of all =
> 32-bit C integer types disappearing, this should provide a sound basis =
> for  
>
>     specifying the size =
> of embedded packed types.   
> 
>
> Summary:  The disappearance of a =
> 32-bit C integer types is extremely unlikely.  Regardless of 205's =
> fate we  
>
> already have 32-bit values tied to =
> unsigned ints.  We are also already at work (separately) on a =
> robust way   
>
> of indicating C data type sizes. =
> 
> 
>
> Ralph Duncan
>
> Mentor Graphics
> 
>
> </BODY>
> </HTML>
> ------_=_NextPart_001_01C4C1BE.5F5D1349--
>
Received on Wed Nov 3 09:36:00 2004

This archive was generated by hypermail 2.1.8 : Wed Nov 03 2004 - 09:36:29 PST

Re: [sv-cc] Item 205: 64-bit concerns