C Primitive Data Type Sizes

[Kip]

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

[Walter Roberson]

In article <xn***************@news.telus.net>,
Kip <Ki*********@TheVertigo.com> 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.

[Kip]

Walter Roberson wrote:

In article <xn***************@news.telus.net>,
Kip <Ki*********@TheVertigo.com> 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

[James McIninch]

<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

[Me]

> 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.

[Lawrence Kirby]

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

[Chris Hills]

In article <xn***************@news.telus.net>, Kip
<Ki*********@TheVertigo.com> writes

Walter Roberson wrote:

In article <xn***************@news.telus.net>,
Kip <Ki*********@TheVertigo.com> 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. :-(

[Walter Roberson]

In article <HA**************@phaedsys.demon.co.uk>,
Chris Hills <ch***@phaedsys.demon.co.uk> wrote:

In article <xn***************@news.telus.net>, Kip
<Ki*********@TheVertigo.com> 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

[Chris Croughton]

On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
<ch***@phaedsys.org> 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

[Gordon Burditt]

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

[Chris Hills]

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes

On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
<ch***@phaedsys.org> 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 /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Kip]

Chris Hills wrote:

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes

On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
<ch***@phaedsys.org> 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

[S.Tobias]

Chris Hills <ch***@phaedsys.org> wrote:

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes

On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
<ch***@phaedsys.org> 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 si***@FamOuS.BedBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Chris Croughton]

On Wed, 6 Jul 2005 08:58:24 +0100, Chris Hills
<ch***@phaedsys.org> wrote:

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes

On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
<ch***@phaedsys.org> 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 Hills]

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes

On Wed, 6 Jul 2005 08:58:24 +0100, Chris Hills
<ch***@phaedsys.org> wrote:

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes

On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
<ch***@phaedsys.org> 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 /\/\/\/\/
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

[Chris Croughton]

On Wed, 6 Jul 2005 12:49:28 +0100, Chris Hills
<ch***@phaedsys.org> wrote:

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes

On Wed, 6 Jul 2005 08:58:24 +0100, Chris Hills
<ch***@phaedsys.org> wrote:

In article <sl******************@ccserver.keris.net>, Chris Croughton
<ch***@keristor.net> writes
On Tue, 5 Jul 2005 10:46:19 +0100, Chris Hills
<ch***@phaedsys.org> 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 Torek]

In article <Ot**************@phaedsys.demon.co.uk>
Chris Hills <ch***@phaedsys.demon.co.uk> 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 <HA**************@phaedsys.demon.co.uk> 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) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Chris Croughton wrote:

<ch***@phaedsys.org> wrote:

<ch***@keristor.net> 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

[Chris Croughton]

On Wed, 06 Jul 2005 17:38:15 GMT, CBFalconer
<cb********@yahoo.com> wrote:

Chris Croughton wrote:

<ch***@phaedsys.org> wrote:

<ch***@keristor.net> 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

[CBFalconer]

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

[Gordon Burditt]

>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.
When commercial programs start requiring 10G of RAM to run, and the
Windows boot track (with its HD-resolution movie of Bill Gates'
birth with audio tracks in 50 languages and the video with 5 different
MPAA ratings) requires 3.5G, you'll see plenty of compilers using
more than 32-bit pointers. Now, the question is, will this be on
the IA64 platform, large-model IA32, or something else?
It could be very useful (for instance
to force every object into its own segment for memory protection).

But the main reason for a large-model compiler is that the size of
one segment (in 32-bit mode, this is 4G) is too constraining. When
you start seeing computers with more than 4G of RAM routinely,
large-model compilers won't be too far behind.

Gordon L. Burditt

[CBFalconer]

Chris Croughton wrote:

<cb********@yahoo.com> wrote:

Chris Croughton wrote:

<ch***@phaedsys.org> wrote:
<ch***@keristor.net> 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).

You chose not to listen. I said the extra portion was common.
Thus it never changes, and need not be stored. The OS has provided
an environment in which 32 bit pointers work. The actuality is
something else.

--
"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

[Keith Thompson]

Chris Hills <ch***@phaedsys.org> writes:
[...]

Some C compilers do have 8 bit shorts and enums.

8-bit enums are perfectly legitimate, of course, but I'd be surprised
to see something claiming to be a C compiler that provides 8-bit
shorts.

Here's the table you posted upthread that triggered this argument:

] 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

There's a shorter version of that table on page 34 of K&R, 1st
Edition. It indicates that the DEC PDP-11 implementation had 16-bit
shorts, as did the IBM 370 and Interdata 8/32; the Honeywell 6000 had
36-bit shorts. In fact, although the range requirements in the C90
standard hadn't been written yet, every implementation listed in the
table in K&R1 would have conformed to them (assuming there weren't too
many padding bits).

Do you have a real-world example of a C compiler with short smaller
than 16 bits? If so, does its documentation actually claim that it's
a "C compiler", or merely that it implements a subset of the language?

You also wrote:

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

I can imagine a compiler for a vaguely C-like language using 3-bit
bytes, but I'd be astonished to see a compiler with 3-bit characters.
You can't even represent all the characters of the basic execution
character set in less than 7 bits. And all your examples have 8-bit
char anyway. Do you have a real-world example of a C-like
implementation with CHAR_BIT < 8?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Chris Croughton]

On Wed, 06 Jul 2005 21:52:01 -0000, Gordon Burditt
<go***********@burditt.org> wrote:

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.
When commercial programs start requiring 10G of RAM to run, and the
Windows boot track (with its HD-resolution movie of Bill Gates'
birth with audio tracks in 50 languages and the video with 5 different
MPAA ratings) requires 3.5G, you'll see plenty of compilers using
more than 32-bit pointers. Now, the question is, will this be on
the IA64 platform, large-model IA32, or something else?

It is very unlikely to be on an 80386, which was the claimed processor.
I don't know of any 80386 systems capable of handling more than 4GB of
RAM.

(Video files can already be much more than 4GB, no one attempts to
handle them in memory...)

It could be very useful (for instance
to force every object into its own segment for memory protection).

But the main reason for a large-model compiler is that the size of
one segment (in 32-bit mode, this is 4G) is too constraining.

That was a major reason with 16 bit offsets, I think a much more likely
reason with 32 bit offsets and lengths will be security, a lot of the
buffer overrun and stale pointer bugs could be caught easily with such a
system. Since in standard C a pointer may only legitimately point to an
allocated object (or one element past it in the case of an array, but it
isn't valid to dereference that) it shouldn't cause too many problems to
non-buggy programs...
When you start seeing computers with more than 4G of RAM routinely,
large-model compilers won't be too far behind.

Indeed, but they are likely to have 64 bit pointers (as some of the
larger processors do already).

The question was about the claim that there are C compilers for the
80386 which use 48 bit pointers...

Chris C

[CBFalconer]

Chris Croughton wrote:

.... snip ...
Indeed, but they are likely to have 64 bit pointers (as some of the
larger processors do already).

The question was about the claim that there are C compilers for the
80386 which use 48 bit pointers...

No, look at the subject line. The question was whether pointer
types of over 32 bits exist for the 386 architecture. They do,
they just aren't used in the currently modish compilers, and this
can be done by setting various segment registers to a constant and
ignoring them thenceforth.

--
"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

[Chris Croughton]

On Thu, 07 Jul 2005 17:12:26 GMT, CBFalconer
<cb********@yahoo.com> wrote:

Chris Croughton wrote:

... snip ...

Indeed, but they are likely to have 64 bit pointers (as some of the
larger processors do already).

The question was about the claim that there are C compilers for the
80386 which use 48 bit pointers...

No, look at the subject line.

Snippage restored:

Chris Croughton wrote:

<ch***@phaedsys.org> wrote:
<ch***@keristor.net> 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.

My question was: Which 80386 C compiler has 48 bit char pointers?
That's a C pointer which takes up 48 bits (6 bytes on that
architecture), in case you still don't understand.
The question was whether pointer
types of over 32 bits exist for the 386 architecture. They do,
they just aren't used in the currently modish compilers,
So your answer is, in fact, 'none', yes? No existing C compiler for the
80386 actually does have 48 bit pointers, true? Has one ever existed
which did that, if so which one? That is what I was asking, not
"whether pointer types of over 32 bits exist for the 386 architecture".
and this
can be done by setting various segment registers to a constant and
ignoring them thenceforth.

Which is irrelevant. I never denied that such a thing could be done
(indeed, I made a point for it being a useful thing to do), I questioned
whether it is actually done.

If it hasn't been done in the past, it's unlikely to be done in the
future, because it's unlikely that anyone will be writing compilers for
the 80386 now that it's been obsolete for years. They may write
compilers for other members of the x86 family which do something
similar...

Chris C

[Chris Croughton]

On Thu, 07 Jul 2005 01:10:36 GMT, CBFalconer
<cb********@yahoo.com> wrote:

Chris Croughton wrote:

<cb********@yahoo.com> wrote:

Chris Croughton wrote:
<ch***@phaedsys.org> wrote:
> <ch***@keristor.net> 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).

You chose not to listen. I said the extra portion was common.
Thus it never changes, and need not be stored. The OS has provided
an environment in which 32 bit pointers work. The actuality is
something else.

No, I am choosing to want an answer to my question, not to some
different question. Which (if any) C compiler for the 80386 uses 48 bit
pointers to char? That means that the pointer takes up 48 bits in
memory (otherwise you could describe the 8086 "small model" pointers as
"32 bits" just because there is a common segment register).

(Indeed, since on the 80386 a "segment register" contains offset and
length plus some control bits it would make your pointers in linear mode
a lot more than 48 bits...)

Chris C