Sizes of Integer Types

[Bob Timpkinson]

Hi,

I have a 32-bit machine... Is there anyway I can get gcc to use the
following integer sizes?
char: 8 bits
short: 16 bits
int: 32 bits
long: 64 bits
long long: 128 bits

Thanks!

Bob.

[christian.bau]

On Sep 13, 6:53 pm, [e-mail] wrote:

This might be a good place to note that N1256, an updated draft
incorporating the new TC3, has just been published:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

-Larry Jones

Lots of thanks for that link.

Now a quiz question: How is page 1 (that is the page after page xiv)
different from all the other pages?

[Flash Gordon]

pete wrote, On 13/09/07 23:43:

Flash Gordon wrote:

>Portability is not binary.

That's right.
It's defined in terms of "little or no modification".

ISO/IEC 2382-l : 1993

01.04.06
portability (of a program)
The capability of a program to be executed on various types
of data processing systems without converting the program
to a different language and with little or no modification.

Note that nowhere does it say *all* data processing systems. This is not
for pete, who obviously understands this, but for those who think that
you are throwing portability out the window if your SW won't run on all
implementations past, present and future.
--
Flash Gordon

[Richard Heathfield]

christian.bau said:

On Sep 13, 6:53 pm, [e-mail] wrote:

>This might be a good place to note that N1256, an updated draft
incorporating the new TC3, has just been published:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

-Larry Jones

Lots of thanks for that link.

Now a quiz question: How is page 1 (that is the page after page xiv)
different from all the other pages?

In finest rec.puzzles tradition, I've included some "spoiler space", so
that those who would rather try to find the answer themselves can do so
by simply not reading this reply any further.
s
p
o
i
l
e
r
s
p
a
c
e
s
p
o
i
l
e
r
s
p
a
c
e s
p
o
i
l
e
r
s
p A N Y
a
c
e s
p
o
i
l
e
r
s
p M O M E N T
a
c
e s
p
o
i
l
e
r
s
p N O W
a
c
e

It doesn't contain a mis-spelling of "September".

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Peter J. Holzer]

On 2007-09-14 23:41, Charlie Gordon <ne**@chqrlie.orgwrote:

"jacob navia" <ja***@jacob.remcomp.fra écrit dans le message de news:
46***********************@news.orange.fr...

>Keith Thompson wrote:

>>"Charlie Gordon" <ne**@chqrlie.orgwrites:
"Al Balmer" <al******@att.neta écrit dans le message de news:
ja********************************@4ax.com...
On Thu, 13 Sep 2007 02:06:56 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:
[...]
>Such biests are disappearing fast at this time,
They are?
Can you name counter examples ?

Aside from the DS9000 and some surviving Unisys mainframes, no one
came up with real life examples of contemporary architectures with
non twos-complement arithmetics, padding bits, trap values and
similar obsolete crap.

[...]

I am calling for examples, and this is not a valid one.
But surely the C99 folks must have had more than a few in mind when they
mulled the Standard.

Keep in mind that this was about 10 years ago. The Unisys mainframes you
mentioned above were still very much in use in the late '90s (the last
model was introduced in 1997), but most of them have probably been
replaced by now or will be when the first compilers for C09 appear, so
they probably won't influence the committee much now. (Speaking of C09:
Will there be a C09 and if so, what can we expect of it?)

hp
--
_ | Peter J. Holzer | I know I'd be respectful of a pirate
|_|_) | Sysadmin WSR | with an emu on his shoulder.
| | | hj*@hjp.at |
__/ | http://www.hjp.at/ | -- Sam in "Freefall"

[Kelsey Bjarnason]

[snips]

On Sat, 15 Sep 2007 00:25:02 +0100, Flash Gordon wrote:

Fixed width types are, IMHO, the perfect types for memory mapped HW.
Since then the HW defines it being N bits wide.

Agreed. They are.

I also see them as useful (but not as important) for interfaces which
will be writing binary data and the specification says the data will be
exactly N bits wide (the routine actually doing the read/write still has
to handle endianness, obviously.

Again, agreed.

Here, however, is the question: before the new int types, were you
prevented from writing such code? Or did writing such code impose a
significant burden on you?

Let's emphasize that a bit: was the code of this sort, for the last 30
years or so, such a burden to write that it actually needed the standard
to be modified to include the new types? Bearing in mind the cost and
effort of actually writing new things into the standard?

So far the answer to that, based on what's been offered here, has been a
resounding "no", yet that's about the only justification thus offered for
these types.

Yes, there are benefits. Do those benefits outweigh the costs? Not as
far as anyone here has even begun to hint at.

[Al Balmer]

On Fri, 14 Sep 2007 11:46:53 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

>>
Arithmetic isn't everything.

Arithmetic can by relied upon more readily than representation.

My point is that computers are used to do other things than
arithmetic. Masking a 16-bit register to 8 bits does not make it an
8-bit register.

--
Al Balmer
Sun City, AZ

[Al Balmer]

On Fri, 14 Sep 2007 11:41:13 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

>"Al Balmer" <al******@att.neta écrit dans le message de news:
ja********************************@4ax.com...

>On Thu, 13 Sep 2007 02:06:56 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

>>>It would have been good to mandate their support on _all_ architectures.
Odd bit sized and non 2's complement machines could emulate them in
software...

For purposes of calculation they could. Probably even for purposes of
satisfying the standard. But there might be times when you actually
need the hardware to be able to write say 16 bits and no more, such as
for writing to a 16-bit memory mapped port, where the adjacent 16 bits
is a different port.

You can't really do that portably. If you need bit addressability to your
hardware, you are beyond the scope of the C language.

Unless you have the stdint types. That's what we're talking about.

>

>>>Such biests are disappearing fast at this time,

They are?

Can you name counter examples ?

There are many wonders in the world of embedded computing.

--
Al Balmer
Sun City, AZ

[Al Balmer]

On Thu, 13 Sep 2007 12:22:47 -0700, Kelsey Bjarnason
<kb********@gmail.comwrote:

>You keep saying that. The new types *are* required to exist

Really? So uint8_t exists on a machine with 64-bit char and short and int
and long? No, it doesn't. Continuing...

>>, if the
implementation can support them.

I give up. There's no point to discussing an issue with someone who
argues by quoting half-sentences. You ran out of rational points long
ago, and are just playing. I have better things to do.

--
Al Balmer
Sun City, AZ

[Al Balmer]

On Thu, 13 Sep 2007 13:53:21 -0400, la************@ugs.com wrote:

>This might be a good place to note that N1256, an updated draft
incorporating the new TC3, has just been published:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

Thank you. Downloading now.

--
Al Balmer
Sun City, AZ

[Charlie Gordon]

"Al Balmer" <al******@att.neta écrit dans le message de news:
0s********************************@4ax.com...

On Fri, 14 Sep 2007 11:46:53 +0200, "Charlie Gordon"
<ne**@chqrlie.orgwrote:

>>>
Arithmetic isn't everything.

Arithmetic can by relied upon more readily than representation.

My point is that computers are used to do other things than
arithmetic. Masking a 16-bit register to 8 bits does not make it an
8-bit register.

What exactly do you call a register? I don't the C standard can help in
dealing with CPU registers or memory mapped I/O registers...

If your implementation gives you adequate control over these, and uint8_t
and uint16_t types are fit for this purpose, no problem.

But for implementing algorithms that require 2s-complement exact size 8, 16,
32 or 64 bits, it would be helpful if the Standard mandated the support of
the corresponding types. The commitee decided it was not helpful enough to
balance the extra work needed for weird platforms, so be it.

I don't quite agree with them, they did mandate long long, and floating
point arithmetics for all conforming platforms, that's more work than
supporting 2s complement 8/16/32 bits arithmetics on the rare if not
inexistent architectures that don't support it already.

I personally regret that it is not possible in C to describe actual data
structures stored in files with more precision. I would want to tell the
compiler about endianness, alignment and representation and have it generate
the best code for the target architecture. Code that deals with memory
mapped files, device driver I/O space, Graphics chips, would be so much more
readable.

--
Chqrlie.