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

Hi all,

thanks a lot to Doug, Jim, and all others for their interest on this topic.
I have submitted a new errata (288) on this, including some first idea
on how to solve it.

Regards,
-Michael

Jim Vellenga wrote:

>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! ***