RE: [sv-cc] Another errata for 32 bit wide items ?

Doug,

Steve Dovich recently obtained a copy of the latest
C standard. He was showing me something interesting
in it yesterday that he'll probably write up later.
Defining uint32_t and int32_t is now semi-required:
That is, if your machine supports 32-bit integer
operations, your compilation system has to define those
two types! But if you don't have 32-bit ops, you don't
have to define them (although you may).

Similarly for several other "standard" widths.

Regards,
Jim V.

---------------------------------------------------------
James H. Vellenga 978-262-6381
Engineering Director (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------
  
 

] -----Original Message-----
] From: Warmke, Doug [mailto:doug_warmke@mentorg.com]
] Sent: Wednesday, October 27, 2004 6:04 PM
] To: Jim Vellenga; michael.rohleder@freescale.com; sv-cc@eda.org
] Subject: RE: [sv-cc] Another errata for 32 bit wide items ?
]
] Jim, others,
]
] I would support modifying the DPI header files to make use
] of some common, well-specified, sized C integer representation.
]
] Unfortunately the various OS and compiler installations
] in use for EDA these days don't have "uint32_t" et al
] defined in a handy one-stop-shopping location.
]
] Here is a snippet for getting "int64_t" and "uint64_t" defined:
]
] #if defined(_MSC_VER)
] typedef __int64 int64_t;
] typedef unsigned __int64 uint64_t;
] #elif defined(__MINGW32__)
] #include <stdint.h>
] #elif defined(__linux)
] #include <inttypes.h>
] #else
] #include <sys/types.h>
] #endif
]
] This works for native compilers as well as gcc on all kinds
] of linux (32 and 64 bit), all kinds of Solaris, all kinds of
] HP-UX, and all kinds of AIX. For Win32 it works for MSC 6.0
] and down; could use a little cleanup for 7.0 (.NET) and up.
]
] Whoever proposes this one should probably carefully consider
] how to standardize on this kind of typedef. We don't want
] to clutter the LRM with too much arcania related to
] present-day operating system configurations.
]
] Regards,
] Doug
]
] > -----Original Message-----
] > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] > Behalf Of Jim Vellenga
] > Sent: Wednesday, October 27, 2004 10:46 AM
] > To: michael.rohleder@freescale.com; sv-cc@eda.org
] > Subject: RE: [sv-cc] Another errata for 32 bit wide items ?
] >
] > First of all, I think it's a very good idea for all
] > of DPI. The number 32 appears so often in Appendix E
] > that we ought to lock the definition down to being
] > a 32-bit type.
] >
] > Secondly, as I understand it, uint32_t is not a C
] > standard type, but one that is provided by a set
] > of system-specific definitions in a separate file.
] > But (again, as I understand it) when it is provided,
] > it always represents a 32-bit type. We might want
] > to allow some room in the standard for systems that
] > don't happen to have it.
] >
] > Thirdly, this is not necessarily required for the
] > PLI header files -- although I think it would be a
] > good idea. Most of PLI doesn't deal in aggregate
] > types, so whether an unsigned int has 32, 36, 48,
] > or 64 bits doesn't make a lot of difference.
] >
] > But as I understand things at the moment, if someone
] > put in a proposal to use uint32_t, I'd be inclined to
] > vote for it.
] >
] > Regards,
] > Jim Vellenga
] >
] > ---------------------------------------------------------
] > James H. Vellenga 978-262-6381
] > Engineering Director (FAX) 978-262-6636
] > Cadence Design Systems, Inc. vellenga@cadence.com
] > 270 Billerica Rd
] > Chelmsford, MA 01824-4179
] > "We all work with partial information."
] > ----------------------------------------------------------
] >
] >
] >
] > ] -----Original Message-----
] > ] From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On
] > ] Behalf Of Michael Rohleder
] > ] Sent: Wednesday, October 27, 2004 1:09 PM
] > ] To: sv-cc@eda.org
] > ] Subject: [sv-cc] Another errata for 32 bit wide items ?
] > ]
] > ] Hi all,
] > ]
] > ] triggered by Ralph's proposal I would like to request to file an
] > ] additional errata.
] > ] If you look at this excerpt from his proposal:
] > ]
] > ] typedef unsigned int svBitActual32;
] > ] typedef struct {unsigned int part1; unsigned int part2;}
] > ] svLogicActual32;
] > ]
] > ] it is obvious that it is ASSUMED that 'unsigned int' is a 32
] > ] bit integer
] > ] value. Since we clearly have
] > ] identified that this is not neccessarily the case for all
] > ] platforms/C-compilers/... we might think about
] > ] replacing 'unsigned int' by 'uint32_t' whenever we assume
] > 32 bit wide
] > ] integer values.
] > ]
] > ] As Ralph pointed out that this is general problem, I suggest
] > ] to file a
] > ] new errata stating that we should
] > ] replace 'all references to unsigned int whenever it is
] assumed that
] > ] unsigned int is 32 bit wide by uint32_t'.
] > ] Alternatively we might borrow one of the PLI specific
] > definitions for
] > ] this task. Ralph pointed out that
] > ] this very likely applies also to E.7.7, and the svBitVec32
] > ] defs, etc. in
] > ] F.1 and 9.1.2.
] > ]
] > ] The idea behind this is that we better don't put in any
] > ] _assumptions_ of
] > ] integer file sizes; instead make
] > ] clear that this is the intended size. To my knowledge uint32_t is
] > ] defined by the C standard as a 32 bit
] > ] wide integer type.
] > ]
] > ] Regards,
] > ] -Michael
] > ]
] > ]
] > ] --
] > ]
] > ] NOTE: The content of this message may contain personal views
] > ] which are not neccessarily the views of Freescale,
] > ] unless specifically stated.
] > ]
] > ] ___________________________________________________
] > ] | |
] > ] _ | Michael Rohleder Tel: +49-89-92103-259 | _
] > ] / )| Freescale Semiconductor Fax: +49-89-92103-680 |( \
] > ] / / | Freescale Halbleiter Deutschland GmbH | \ \
] > ] _( (_ | _ Schatzbogen 7, D-81829 Munich, Germany
] _ | _) )_
] > ] (((\ \>|_/ > <
] \_|</ /)))
] > ] (\\\\ \_/ / mailto:Michael.Rohleder@freescale.com \
] > \_/ ////)
] > ] \
] /_______________________________________________\ /
] > ] \ _/ \_ /
] > ] / / \ \
] > ]
] > ] The information contained in this email has been classified as:
] > ] General Business Information ( )
] > ] Freescale Internal Use Only ( )
] > ] Freescale Confidential Proprietary ( )
] > ]
] > ]
] > ] *** This note may contain Freescale Confidential Proprietary
] > ] or Freescale Internal Use Only Information and is intended to
] > ] be reviewed by only the individual or organization named
] > ] above. If you are not the intended recipient or an authorized
] > ] representative of the intended recipient, you are hereby
] > ] notified that any review, dissemination or copying of this
] > ] email and its attachments, if any, or the information
] > ] contained herein is prohibited. If you have received this
] > ] email in error, please immediately notify the sender by
] > ] return email and delete this email from your system.
] > ] Thank you! ***
] > ]
] > ]
] > ]
] > ]
] > ]
] >
] >
]
]
Received on Thu Oct 28 05:56:07 2004