RE: one SystemVerilog inconsistency cleared up

John,

I'd suggest making your table explicitly list on separate rows the use of
the 'unsigned' post qualifier on each size of SV integer type and the
corresponding C type (even if the SV LRM writers want to publish an
incomplete table).

Perhaps, when we get around to fine detail in the eventual spec, we should
emphasize the usage of the several unsigned SV types as a "good" way to pass
by value bit vectors <= 32 bits long.

-russ

---------------------------------------
---    Russ Vreeland (949)926-6143  ---
---    vreeland@broadcom.com        ---
---    Senior Principal Engineer    ---
---    Broadcom Corporation         ---
---------------------------------------



> -----Original Message-----
> From: owner-itc@eda.org [mailto:owner-itc@eda.org] On Behalf 
> Of John Stickley
> Sent: Thursday, August 04, 2005 4:34 PM
> To: Bojsen, Per; Russell Vreeland
> Cc: 'itc@eda.org'
> Subject: one SystemVerilog inconsistency cleared up
> 
> 
> Per and Russ,
> 
> I was just reading over the SystemVerilog LRM Draft6 again 
> (this time more carefully !) and realized that the text 
> itself acknowledges that the type mapping table F-1 is incomplete.
> 
> The following statement appears shortly after the table:
> 
> "The DPI interface also supports the SystemVerilog and C 
> unsigned integer 
> data types that correspond to the mappings
> Table F-1 shows for their signed equivalents."
> 
> So basically any SV integer type can have a post qualifier 
> 'unsigned' that makes it unsigned. That would map to the 
> corresponding unsigned type in C.
> 
> For example 'byte' denotes a signed 8 bit integer that maps 
> to 'char'. But 'byte unsigned' denotes an unsigned 8 bit 
> integer that maps to 'unsigned char'.
> 
> So this is saying both signed and unsigned types are 
> supported across the interface the way we would like and also 
> there is no inconsistency between byte and the rest of the 
> int types with regard to 
> signs (somehow I had misread that earlier). Which is good 
> news and at least alleviates some of the concerns we had 
> today regarding signed to unsigned casting, sign extensions 
> on coercions, etc.
> 
> I'll revise the new draft of the proposal accordingly and I 
> will make the tables more complete.
> 
> -- johnS
> 
> 
> ______________________________/\/            \     \
> John Stickley                   \             \     \
> Mgr., Acceleration Methodologies \             \________________
> Mentor Graphics - MED             \_
> ________________________________________________________________
>