C Primitive Data Type Sizes

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

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.

 

[Keith Thompson]

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?

 

[Chris Croughton]

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

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]

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

 

[Chris Croughton]

No, look at the subject line.

Snippage restored:

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]

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