C Primitive Data Type Sizes

Discussion in 'C Programming' started by Kip, Jul 4, 2005.

  1. Kip

    Kip Guest

    Greetings everyone,

    Is there anyone here who could point me to a page or pdf that has a
    list of the sizes of all of the C primitive data types on various
    implementations such as SPARC, x86, PowerPC, etc?

    Thank you.

    --
    Kip Warner
    Vertigo
    http://TheVertigo.com
    Kip, Jul 4, 2005
    #1
    1. Advertising

  2. In article <>,
    Kip <> wrote:
    >Is there anyone here who could point me to a page or pdf that has a
    >list of the sizes of all of the C primitive data types on various
    >implementations such as SPARC, x86, PowerPC, etc?


    You listed chips, but C primitive types can be (and often
    have been) implimented in library code.

    The size of C primitive types is dependant on the compiler...
    which usually takes hints from the underlying hardware, but is
    not bound by it.
    --
    Usenet is like a slice of lemon, wrapped around a large gold brick.
    Walter Roberson, Jul 5, 2005
    #2
    1. Advertising

  3. Kip

    Kip Guest

    Walter Roberson wrote:

    > In article <>,
    > Kip <> wrote:
    > > Is there anyone here who could point me to a page or pdf that has a
    > > list of the sizes of all of the C primitive data types on various
    > > implementations such as SPARC, x86, PowerPC, etc?

    >
    > You listed chips, but C primitive types can be (and often
    > have been) implimented in library code.
    >
    > The size of C primitive types is dependant on the compiler...
    > which usually takes hints from the underlying hardware, but is
    > not bound by it.


    Thanks. But it still begs the question of whether or not anyone here
    could point me to a page or pdf that has a list of the sizes on all of
    the C primitive data types on various implementations?

    --
    Kip Warner
    Vertigo
    http://TheVertigo.com
    Kip, Jul 5, 2005
    #3
  4. <posted & mailed>

    No. The sizes are dependent not only on the processor, but also the
    operating environment and, in some cases, the compiler used. Consult the
    compiler documentation for each that you are interested in.


    Kip wrote:

    > Greetings everyone,
    >
    > Is there anyone here who could point me to a page or pdf that has a
    > list of the sizes of all of the C primitive data types on various
    > implementations such as SPARC, x86, PowerPC, etc?
    >
    > Thank you.
    >


    --
    Remove '.nospam' from e-mail address to reply by e-mail
    James McIninch, Jul 5, 2005
    #4
  5. Kip

    Me Guest

    > Is there anyone here who could point me to a page or pdf that has a
    > list of the sizes of all of the C primitive data types on various
    > implementations such as SPARC, x86, PowerPC, etc?


    The answer to your question is probably meaningless for what you're
    trying to determine anyway (other than knowing about the data types of
    existing C implementations, which is a bad question to ask IMHO).
    Knowing the size of primitive data types tells you nothing about them
    except how much space they take up in relation to a char. It doesn't
    tell you anything about how many padding bits a type has, what encoding
    it uses for signed integers, alignment requirements, bit ordering, trap
    representations, etc. And an implementation of C doesn't depend on the
    underlying hardware, it depends on the C compiler and whatever possible
    modes it supports. It's entirely possible for it to emulate 9-bit chars
    on an 8-bit machine for example. Why would it do something like that?
    Well because it's free to do so and it helps debug non-portable
    assumptions about C for those of us that prefer to write code according
    to what the standard guarantees a conforming implementation must
    support.
    Me, Jul 5, 2005
    #5
  6. On Mon, 04 Jul 2005 23:58:28 +0000, Kip wrote:

    ....

    > Thanks. But it still begs the question of whether or not anyone here
    > could point me to a page or pdf that has a list of the sizes on all of
    > the C primitive data types on various implementations?


    I don't know of such a list offhand. I'm curious to know however what you
    would use such a list for if you find one.

    Lawrence
    Lawrence Kirby, Jul 5, 2005
    #6
  7. Kip

    Chris Hills Guest

    In article <>, Kip
    <> writes
    >Walter Roberson wrote:
    >
    >> In article <>,
    >> Kip <> wrote:
    >> > Is there anyone here who could point me to a page or pdf that has a
    >> > list of the sizes of all of the C primitive data types on various
    >> > implementations such as SPARC, x86, PowerPC, etc?

    >>
    >> You listed chips, but C primitive types can be (and often
    >> have been) implimented in library code.
    >>
    >> The size of C primitive types is dependant on the compiler...
    >> which usually takes hints from the underlying hardware, but is
    >> not bound by it.

    >
    >Thanks. But it still begs the question of whether or not anyone here
    >could point me to a page or pdf that has a list of the sizes on all of
    >the C primitive data types on various implementations?


    I doubt such a list exists.

    start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there :)
    the problem is that there are very many architectures still in use if
    not common.

    type pdp11 vax 68000 Cray-2 Unisys Harris 80386
    series family 1100 H800

    char 8 8 8 8 9 8 8
    short 8 8/16 16/16 64(32) 18 24 8/16
    int 16 16/32 16/32 64(32) 36 24 16/32
    long 32 32 32 64 36 48 32
    char * 16 32 32 64 72 24 16/32/48
    int * 16 32 32 64(24) 72 24 16/32/64
    int (*) 16 32 32 64 56 24 16/32/64




    This list is not exhaustive by a LONG LONG way. :-(
    Chris Hills, Jul 5, 2005
    #7
  8. In article <>,
    Chris Hills <> wrote:
    >In article <>, Kip
    ><> writes


    >>Thanks. But it still begs the question of whether or not anyone here
    >>could point me to a page or pdf that has a list of the sizes on all of
    >>the C primitive data types on various implementations?


    >I doubt such a list exists.


    >start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there :)


    Though fortunately char sizes smaller than 8 are not compatible with
    the standards, so we do not have to worry about those cases when dealing
    with standard C. (One might have to worry about them if one is
    writing for a version of C adapted for a specialized processor.)


    >the problem is that there are very many architectures still in use if
    >not common.


    And the answer can depend on how one compiles...

    >type pdp11 vax 68000 Cray-2 Unisys Harris 80386
    > series family 1100 H800



    I hope that examing this table of one signal OS's processor family
    will convince Kip that in listing major chips lines, he is asking the
    wrong question.


    SGI, MIPS chips, compiled with SGI's cc compilers in -coff mode
    char 8, short 16, int 32, long 32, char * 32, int * 32, int (*) 32

    R2000 - IRIX 2, IRIX 3.1, IRIX 3.2
    R3000 - IRIX 3.2, IRIX 3.3, IRIX 4.*, IRIX 5.*
    R4000 - IRIX 4.0.3 - IRIX 5.*
    R4400 - IRIX 5.3
    R4600PC - IRIX 5.2 for Indy R4600PC & Challenge S, IRIX 5.3
    R4600SC - IRIX 5.2 for Indy R4600SC/XZ & Presenter, IRIX 5.3
    R5000 - IRIX 5.3
    R8000 - IRIX 6.0, IRIX 6.1
    R10000 - not supported
    R12000 - not supported
    R14000 - not supported


    SGI, MIPS chips, compiled with SGI's cc compilers in -o32 mode or -n32 mode
    char 8, short 16, int 32, long 32, char * 32, int * 32, int (*) 32
    (Note: -o32 mode does not support any 64 bit system calls such as stat64()
    or lseek64(), and file sizes are limited to 2 GB. -n32 mode does not
    have these restrictions.)

    R2000 - not supported
    R3000 - not supported
    R4000 - IRIX 6.2*, IRIX 6.5 - IRIX 6.5.13-ish
    R4400 - IRIX 6.2*, IRIX 6.5 - IRIX 6.5.22
    R4600PC - IRIX 6.2*, IRIX 6.5 - IRIX 6.5.?
    R4600SC - IRIX 6.2*, IRIX 6.5 - IRIX 6.5.?
    R5000 - IRIX 5.3 for R5000 Indy, IRIX 5.3 Indy R5000 with XFS, IRIX 6.2,
    IRIX 6.3, IRIX 6.5 - IRIX 6.5.22
    R8000 - IRIX 6.0*, IRIX 6.1, IRIX 6.5
    R10000 - IRIX 6.2, IRIX 6.5.*
    R12000 - early IRIX 6.5.* onward
    R14000 - somewhere near IRIX 6.5.17 onward
    R16000 - somewhere near IRIX 6.5.23 onward


    SGI, MIPS chips, compiled with SGI's cc compilers in -64 mode
    char 8, short 16, int 32, long 64, char * 64, int * 64, int (*) 64

    R2000 - not supported
    R3000 - not supported
    R4000 - not supported.
    Note: the R4000 has full support for 64 bit arithmetic, and was
    -designed- to support 64 bit pointers, but it had a bug in the chip mask
    that made 64 bit pointers impractical.
    R4400 - IRIX 6.2, IRIX 6.5 - IRIX 6.5.22
    R4600PC - not supported
    R4600SC - not supported
    R5000 - not supported
    R8000 - IRIX 6.1, IRIX 6.5 - IRIX 6.5.22
    R10000 - IRIX 6.2, IRIX 6.4, IRIX 6.5*
    R12000 - early IRIX 6.5.* onward
    R14000 - somewhere near IRIX 6.5.17 onward
    R16000 - somewhere near IRIX 6.5.23 onward
    --
    "Never install telephone wiring during a lightning storm." -- Linksys
    Walter Roberson, Jul 5, 2005
    #8
  9. On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
    <> wrote:

    > start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there :)


    Er, char can only be 8 bits or more (at least in standard C). But my
    favourite implementation of the DS9000 has char as 11 bits:

    sizeof short 2
    sizeof int 3
    sizeof long 5
    sizeof long long 7

    > the problem is that there are very many architectures still in use if
    > not common.
    >
    > type pdp11 vax 68000 Cray-2 Unisys Harris 80386
    > series family 1100 H800
    >
    > char 8 8 8 8 9 8 8
    > short 8 8/16 16/16 64(32) 18 24 8/16


    8 bit short is not allowed by the standard.

    > int 16 16/32 16/32 64(32) 36 24 16/32
    > long 32 32 32 64 36 48 32
    > char * 16 32 32 64 72 24 16/32/48


    Which 80386 compiler has 48 bit char pointers? Just curious...

    > int * 16 32 32 64(24) 72 24 16/32/64
    > int (*) 16 32 32 64 56 24 16/32/64
    >
    > This list is not exhaustive by a LONG LONG way. :-(


    Or even a long double way <g>...

    Chris C
    Chris Croughton, Jul 5, 2005
    #9
  10. >> type pdp11 vax 68000 Cray-2 Unisys Harris 80386
    >> series family 1100 H800
    >>
    >> char * 16 32 32 64 72 24 16/32/48

    >
    >Which 80386 compiler has 48 bit char pointers? Just curious...


    Any large-model 32-bit-mode i*86 compiler would need this, so you're
    not limited to only 4GB code or only 4GB data (the pointer includes
    the segment register, for a total of 48 bits). As to whether there
    actually are any on the market, I'm not sure.

    Gordon L. Burditt
    Gordon Burditt, Jul 5, 2005
    #10
  11. Kip

    Chris Hills Guest

    In article <>, Chris Croughton
    <> writes
    >On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
    > <> wrote:
    >
    >> start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there :)

    >
    >Er, char can only be 8 bits or more (at least in standard C).


    The OP was asking about IMPLEMENTATIONS.... This is not comp.lang.std.c
    To be fair most of the machines with "odd" size chars are rather old and
    not common.

    > But my
    >favourite implementation of the DS9000 has char as 11 bits:
    >
    > sizeof short 2
    > sizeof int 3
    > sizeof long 5
    > sizeof long long 7
    >
    >> the problem is that there are very many architectures still in use if
    >> not common.
    >>
    >> type pdp11 vax 68000 Cray-2 Unisys Harris 80386
    >> series family 1100 H800
    >>
    >> char 8 8 8 8 9 8 8
    >> short 8 8/16 16/16 64(32) 18 24 8/16

    >
    >8 bit short is not allowed by the standard.


    The OP asked for a set of primitive data types used on various
    implementations. The C standard is only a starting point. The OP was
    asking for Reality.

    >
    >> int 16 16/32 16/32 64(32) 36 24 16/32
    >> long 32 32 32 64 36 48 32
    >> char * 16 32 32 64 72 24 16/32/48

    >
    >Which 80386 compiler has 48 bit char pointers? Just curious...


    It has segment address in it.

    >> int * 16 32 32 64(24) 72 24 16/32/64
    >> int (*) 16 32 32 64 56 24 16/32/64
    >>
    >> This list is not exhaustive by a LONG LONG way. :-(

    >
    >Or even a long double way <g>...
    >
    >Chris C


    :)



    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris Hills, Jul 6, 2005
    #11
  12. Kip

    Kip Guest

    Chris Hills wrote:

    > In article <>, Chris Croughton
    > <> writes
    > > On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
    > > <> wrote:
    > >
    > >> start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there

    > :)
    > >
    > > Er, char can only be 8 bits or more (at least in standard C).

    >
    > The OP was asking about IMPLEMENTATIONS.... This is not
    > comp.lang.std.c To be fair most of the machines with "odd" size chars
    > are rather old and not common.
    >
    > > But my
    > > favourite implementation of the DS9000 has char as 11 bits:
    > >
    > > sizeof short 2
    > > sizeof int 3
    > > sizeof long 5
    > > sizeof long long 7
    > >
    > >> the problem is that there are very many architectures still in use

    > if >> not common.
    > >>
    > >> type pdp11 vax 68000 Cray-2 Unisys Harris 80386
    > >> series family 1100 H800
    > >>
    > >> char 8 8 8 8 9 8 8
    > >> short 8 8/16 16/16 64(32) 18 24 8/16

    > >
    > > 8 bit short is not allowed by the standard.

    >
    > The OP asked for a set of primitive data types used on various
    > implementations. The C standard is only a starting point. The OP was
    > asking for Reality.
    >
    > >
    > >> int 16 16/32 16/32 64(32) 36 24 16/32
    > >> long 32 32 32 64 36 48 32
    > >> char * 16 32 32 64 72 24 16/32/48

    > >
    > > Which 80386 compiler has 48 bit char pointers? Just curious...

    >
    > It has segment address in it.
    >
    > >> int * 16 32 32 64(24) 72 24 16/32/64
    > >> int (*) 16 32 32 64 56 24 16/32/64
    > >>
    > >> This list is not exhaustive by a LONG LONG way. :-(

    > >
    > > Or even a long double way <g>...
    > >
    > > Chris C

    >
    > :)


    lol, thanks Chris ;)

    --
    Kip Warner
    Vertigo
    http://TheVertigo.com
    Kip, Jul 6, 2005
    #12
  13. Kip

    S.Tobias Guest

    Chris Hills <> wrote:
    > In article <>, Chris Croughton
    > <> writes
    >>On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
    >> <> wrote:


    >>Er, char can only be 8 bits or more (at least in standard C).

    >
    > The OP was asking about IMPLEMENTATIONS....


    He asked about C primitive types.

    >This is not comp.lang.std.c


    No, it's definitely not comp.lang.std.c. It's not comp.std.c either. :)

    >>> type pdp11 vax 68000 Cray-2 Unisys Harris 80386
    >>> series family 1100 H800
    >>>
    >>> char 8 8 8 8 9 8 8
    >>> short 8 8/16 16/16 64(32) 18 24 8/16


    This list is present in one of the versions of "Indian Hill C".

    --
    Stan Tobias
    mailx `echo LID | sed s/[[:upper:]]//g`
    S.Tobias, Jul 6, 2005
    #13
  14. On Wed, 6 Jul 2005 08:58:24 +0100, Chris Hills
    <> wrote:

    > In article <>, Chris Croughton
    > <> writes
    >>On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
    >> <> wrote:
    >>
    >>> start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there :)

    >>
    >>Er, char can only be 8 bits or more (at least in standard C).

    >
    > The OP was asking about IMPLEMENTATIONS.... This is not comp.lang.std.c
    > To be fair most of the machines with "odd" size chars are rather old and
    > not common.


    No C implementation can have char with less than 8 bits. There may be
    implementations of some language which looks vaguely like C which do
    that, but they are not C implementations.

    >>8 bit short is not allowed by the standard.

    >
    > The OP asked for a set of primitive data types used on various
    > implementations. The C standard is only a starting point. The OP was
    > asking for Reality.


    And in Reality there are no C implementations with short less than 16
    bits. There may be implementations of some language which looks vaguely
    like C which do that, but they are not C implementations.

    >>
    >>> int 16 16/32 16/32 64(32) 36 24 16/32
    >>> long 32 32 32 64 36 48 32
    >>> char * 16 32 32 64 72 24 16/32/48

    >>
    >>Which 80386 compiler has 48 bit char pointers? Just curious...

    >
    > It has segment address in it.


    As I asked, which 80386 C compiler does that? All the ones I've seen
    either operated in 16 bit segment + 16 bit offset mode (usually with a
    non-C 'far' qualifier) or in linear address mode with only 32 bits. (If
    it needs a special qualifier such as 'far' then it is not C nor is it a
    "primitive data type".)

    Chris C
    Chris Croughton, Jul 6, 2005
    #14
  15. Kip

    Chris Hills Guest

    In article <>, Chris Croughton
    <> writes
    >On Wed, 6 Jul 2005 08:58:24 +0100, Chris Hills
    > <> wrote:
    >
    >> In article <>, Chris Croughton
    >> <> writes
    >>>On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
    >>> <> wrote:
    >>>
    >>>> start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there :)
    >>>
    >>>Er, char can only be 8 bits or more (at least in standard C).

    >>
    >> The OP was asking about IMPLEMENTATIONS.... This is not comp.lang.std.c
    >> To be fair most of the machines with "odd" size chars are rather old and
    >> not common.

    >
    >No C implementation can have char with less than 8 bits. There may be
    >implementations of some language which looks vaguely like C which do
    >that, but they are not C implementations.
    >
    >>>8 bit short is not allowed by the standard.

    >>
    >> The OP asked for a set of primitive data types used on various
    >> implementations. The C standard is only a starting point. The OP was
    >> asking for Reality.

    >
    >And in Reality there are no C implementations with short less than 16
    >bits. There may be implementations of some language which looks vaguely
    >like C which do that, but they are not C implementations.


    There is always some comedian that brings up this bollox. They have a
    supercilious and self righteous view of the world. By this sort of
    criteria there are no C compiler suites in the world and C is a minority
    language.

    In reality there are many deviations from ISO-C.... by which I mean C90
    and not C99. Most compilers manage C90+ bits and pieces but there are no
    complete C99 compiler systems in the world. I know of one but this has a
    very small market share and uses a library from another source.

    So you can either take the Croughton Theoretical View In which case the
    answer to the OP is that are NO implementations of [ISO-] C [9899:1999]
    in use OR take the realistic view of what actually happens in the real
    world implementations in which case some "C" systems do use 8 bit
    shorts and emuns.

    The OP was talking about IMPLEMENTATIONS ie the real world tools that
    talk t the real world hardware.

    this is why newly qualified graduates are usually considered dangerous
    when they enter the work place. They know the theory but have yet to
    learn the harsh realities of life.

    Some C compilers do have 8 bit shorts and enums.

    --
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
    \/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
    /\/\/ www.phaedsys.org \/\/\
    \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
    Chris Hills, Jul 6, 2005
    #15
  16. On Wed, 6 Jul 2005 12:49:28 +0100, Chris Hills
    <> wrote:

    > In article <>, Chris Croughton
    > <> writes
    >>On Wed, 6 Jul 2005 08:58:24 +0100, Chris Hills
    >> <> wrote:
    >>
    >>> In article <>, Chris Croughton
    >>> <> writes
    >>>>On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
    >>>> <> wrote:
    >>>>
    >>>>> start with:- Char 3,4,5,6,7,8,9 bits and go down hill from there :)
    >>>>
    >>>>Er, char can only be 8 bits or more (at least in standard C).
    >>>
    >>> The OP was asking about IMPLEMENTATIONS.... This is not comp.lang.std.c
    >>> To be fair most of the machines with "odd" size chars are rather old and
    >>> not common.

    >>
    >>No C implementation can have char with less than 8 bits. There may be
    >>implementations of some language which looks vaguely like C which do
    >>that, but they are not C implementations.
    >>
    >>>>8 bit short is not allowed by the standard.
    >>>
    >>> The OP asked for a set of primitive data types used on various
    >>> implementations. The C standard is only a starting point. The OP was
    >>> asking for Reality.

    >>
    >>And in Reality there are no C implementations with short less than 16
    >>bits. There may be implementations of some language which looks vaguely
    >>like C which do that, but they are not C implementations.

    >
    > There is always some comedian that brings up this bollox. They have a
    > supercilious and self righteous view of the world. By this sort of
    > criteria there are no C compiler suites in the world and C is a minority
    > language.


    Wrong. There are plenty of compilers which manage to implement C90.
    Some of them also implement other languages (one popular one, for
    instance, also implements C++, Objective C and by default a bastard
    C90/C99 with non-standard extensions).

    > In reality there are many deviations from ISO-C.... by which I mean C90
    > and not C99. Most compilers manage C90+ bits and pieces but there are no
    > complete C99 compiler systems in the world. I know of one but this has a
    > very small market share and uses a library from another source.


    Did you read what you wrote? "...there are no complete C99 compiler
    systems in the world. I know of one". Either there are none or there is
    one (or more), which is it? I've heard of at least one (it's a
    front-end to several other compilers). Whether the same people produced
    the library or not is irrelevant, no one person writes any major
    compiler these days.

    > So you can either take the Croughton Theoretical View In which case the
    > answer to the OP is that are NO implementations of [ISO-] C [9899:1999]
    > in use OR take the realistic view of what actually happens in the real
    > world implementations in which case some "C" systems do use 8 bit
    > shorts and emuns.


    There is at least one validated implementation of C99 (INCITS/ISO/IEC
    9899:1999) compiler, and at least one implementation of the library.

    No implementation of C90 or C99 uses 8 bit short (they can use 8 bit
    enum if they like - para 6.7.2.2(4) says that "Each enumerated type
    shall be compatible with char, a signed integer type, or an
    unsigned integer type").

    > The OP was talking about IMPLEMENTATIONS ie the real world tools that
    > talk t the real world hardware.


    Yes, if it is an implementation of C then it will have short as at least
    16 bits and char as at least 8 bits. There are plenty in the real
    world, talking to real hardware.

    > Some C compilers do have 8 bit shorts and enums.


    No, they don't. They are compilers of some language like C, but not C
    compilers. Of course some manufacturers may call them "C compilers",
    but that's the problem with gullible customers (perhaps those graduates
    you mentioned) who are willing to buy something when they don't know
    what it's supposed to do. Unfortunately the Trade Descriptions and Sale
    Of Goods acts don't generally get applied to software.

    Chris C
    Chris Croughton, Jul 6, 2005
    #16
  17. Kip

    Chris Torek Guest

    In article <>
    Chris Hills <> wrote:
    >The OP was asking about IMPLEMENTATIONS.... This is not comp.lang.std.c


    Sure it is.

    "It's *spelled* Raymond Luxury Yacht, but it's *pronounced*
    Throat-Wobbler Mangrove!"

    :)

    On a somewhat more serious note...

    In article <> Chris Hills also wrote:
    >>> type pdp11 vax 68000 Cray-2 Unisys Harris 80386
    >>> series family 1100 H800
    >>>
    >>> char 8 8 8 8 9 8 8
    >>> short 8 8/16 16/16 64(32) 18 24 8/16


    All PDP-11 implementations always had 16-bit "short"s. All VAX
    implementations also always had 16-bit "short"s.

    The only C compilers I ever saw with fewer than 16 bits for
    "short" predated the 1989 C standard, and were for 8080 and Z80
    and similarly, ah, ALU-deficient CPUs. :)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Jul 6, 2005
    #17
  18. Kip

    CBFalconer Guest

    Chris Croughton wrote:
    > <> wrote:
    >> <> writes
    >>

    .... snip ...
    >>>
    >>> Which 80386 compiler has 48 bit char pointers? Just curious...

    >>
    >> It has segment address in it.

    >
    > As I asked, which 80386 C compiler does that? All the ones I've
    > seen either operated in 16 bit segment + 16 bit offset mode
    > (usually with a non-C 'far' qualifier) or in linear address mode
    > with only 32 bits. (If it needs a special qualifier such as 'far'
    > then it is not C nor is it a "primitive data type".)


    The so-called linear addressing x86s are really using underlying
    segment registers all set to point to the same large segment. I'm
    not sure whether those segment registers have 16 or 32 (or
    something else) content, and I'm not about to bother checking. At
    any rate they control access to segment tables, that have such
    things as segment limits and access allowances recorded. So every
    '386 up compiler already uses a minimum of 48 bits for a pointer,
    it just uses a common value for the part past the first 32 bits.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    CBFalconer, Jul 6, 2005
    #18
  19. On Wed, 06 Jul 2005 17:38:15 GMT, CBFalconer
    <> wrote:

    > Chris Croughton wrote:
    >> <> wrote:
    >>> <> writes
    >>>

    > ... snip ...
    >>>>
    >>>> Which 80386 compiler has 48 bit char pointers? Just curious...
    >>>
    >>> It has segment address in it.

    >>
    >> As I asked, which 80386 C compiler does that? All the ones I've
    >> seen either operated in 16 bit segment + 16 bit offset mode
    >> (usually with a non-C 'far' qualifier) or in linear address mode
    >> with only 32 bits. (If it needs a special qualifier such as 'far'
    >> then it is not C nor is it a "primitive data type".)

    >
    > The so-called linear addressing x86s are really using underlying
    > segment registers all set to point to the same large segment. I'm
    > not sure whether those segment registers have 16 or 32 (or
    > something else) content, and I'm not about to bother checking. At
    > any rate they control access to segment tables, that have such
    > things as segment limits and access allowances recorded. So every
    > '386 up compiler already uses a minimum of 48 bits for a pointer,
    > it just uses a common value for the part past the first 32 bits.


    No, it is using a 32 bit pointer with 'magic'. Do sizeof(char*) and it
    will be 4, not 6 (with CHAR_BIT == 8).

    It is theoretically possible to have an x86 compiler which used segment
    + a 32 bit offset, and therefore 48 (or more) pointers, but I've never
    heard of one actually doing it. It could be very useful (for instance
    to force every object into its own segment for memory protection).

    Chris C
    Chris Croughton, Jul 6, 2005
    #19
  20. Kip

    CBFalconer Guest

    Chris Hills wrote:
    >

    .... snip ...
    >
    > The OP was talking about IMPLEMENTATIONS ie the real world tools
    > that talk t the real world hardware.
    >
    > this is why newly qualified graduates are usually considered
    > dangerous when they enter the work place. They know the theory
    > but have yet to learn the harsh realities of life.
    >
    > Some C compilers do have 8 bit shorts and enums.


    Why in heavens name should they? They presumably have 8 bit bytes,
    and can go ahead and do arithmetic and storage with those. They
    have absolutely no need for an 8 bit short. Its only purpose seems
    to be to make the code non-portable.

    I would much rather develop and test as much as possible of my code
    on a full fledged system, with such things as easy modification,
    debug tracking, etc. etc. etc. I don't need such debugged modules
    and functions suddenly failing because they are running on an
    inferior system.

    --
    "If you want to post a followup via groups.google.com, don't use
    the broken "Reply" link at the bottom of the article. Click on
    "show options" at the top of the article, then click on the
    "Reply" at the bottom of the article headers." - Keith Thompson
    CBFalconer, Jul 6, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. DaKoadMunky
    Replies:
    8
    Views:
    3,306
    Leor Zolman
    May 14, 2004
  2. Replies:
    7
    Views:
    599
    Victor Bazarov
    May 9, 2005
  3. Kip
    Replies:
    1
    Views:
    398
    Jack Klein
    Jul 5, 2005
  4. Replies:
    2
    Views:
    424
  5. Daniel Pitts
    Replies:
    7
    Views:
    470
Loading...

Share This Page