integral types

[SasQ]

Hello.

I'm wondering about something...
Is C++ designed for 32-bit-and-more machines only?
I've deduced it from the fact that a 'long int' type has to be
at least 32-bit. Am I right or not? :|
Is it possible to use C++ for some embedded platforms using
16-bit or 8-bit integral arithmetics? If yes, how can it be done?
Would 32-bit integers have to be emulated by implementation?
Or maybe by dropping out the 'long int' type? [but is it still
standard-complaint then?]

 

[Alf P. Steinbach]

* SasQ:

I'm wondering about something...
Is C++ designed for 32-bit-and-more machines only?
No.


I've deduced it from the fact that a 'long int' type has to be
at least 32-bit. Am I right or not? :|

'long int' has to be at least 32 bits.

Is it possible to use C++ for some embedded platforms using
16-bit or 8-bit integral arithmetics?
Yes.


If yes, how can it be done?

Using a compiler for that platform, or perhaps a cross-compiler.

Would 32-bit integers have to be emulated by implementation?
Yes.


Or maybe by dropping out the 'long int' type? [but is it still
standard-complaint then?]

No, it wouldn't be standard-compliant by dropping 'long int', but the
C++ standard differentiates between "hosted" and "free-standing"
implementations, the latter being meant primarily for embedded work,
allowed to drop (not offer) most of the standard library.

 

[Kai-Uwe Bux]

Hello.

I'm wondering about something...
Is C++ designed for 32-bit-and-more machines only?

No. C++ is designed for use on parameterized nondeterministic abstract
machines only (see [1.9/1]). That there are C++ compilers for real machines
is a quite astonishing miracle regardless of their word length.

I've deduced it from the fact that a 'long int' type has to be
at least 32-bit. Am I right or not? :|

You are right in that long int has at least 32 bits. But I don't see how
this implies anything about what C++ is designed for.

Is it possible to use C++ for some embedded platforms using
16-bit or 8-bit integral arithmetics?

Is that a question about the availability of C++ compilers for those
platforms? If so, I suggest you investigate the particular platform you are
interested in.

If yes, how can it be done? Would 32-bit integers have to be emulated by
implementation?

Yes, that would be the way to go.

Or maybe by dropping out the 'long int' type? [but is it still
standard-complaint then?]

That would not be standard compliant.


Now, if you find that the compiler generated code to deal with 32 bit
integer types is too bulky or slow and if you were willing to sacrifice the
long integral types anyway, then you should find it acceptable to just not
use the long integral types.


Best

Kai-Uwe Bux

 

[Alf P. Steinbach]

* Kai-Uwe Bux:

Hello.

I'm wondering about something...
Is C++ designed for 32-bit-and-more machines only?

No. C++ is designed for use on parameterized nondeterministic abstract
machines only (see [1.9/1]). That there are C++ compilers for real machines
is a quite astonishing miracle regardless of their word length.

That would be astonishing if C++ was defined in terms of the abstract
machine -- because then seemingly the definition of the abstract
machine itself would be nowhere to be found (searching the standard for
"Vienna" or something like that would not yield any results, I think).

Happily it's not the case that C++ is defined in terms of an abstract
machine.

The C++ standard defines the effects of execution of a C++ program /as/
an abstract machine, i.e., the abstract machine is the effect of a C++
program as per the rules for C++ programs. Sort of the other way from
being defined in terms of. Which in particular means that statements in
the standard about the effect of any construct should not be interpreted
as the effect within some abstract machine (which would yield an
infinitely recursive and impotent definition); instead it is directly
the effect of the construct, and that /is/ the abstract machine.

And the effects of various C++ constructs (and thereby, of the abstract
machine, which is sum total of such effects) have been very carefully
crafted to correspond to and be efficient on actual machines.

C++, and C, are practical engineers' languages.

 

[Kai-Uwe Bux]

* Kai-Uwe Bux:

Hello.

I'm wondering about something...
Is C++ designed for 32-bit-and-more machines only?

No. C++ is designed for use on parameterized nondeterministic abstract
machines only (see [1.9/1]). That there are C++ compilers for real
machines is a quite astonishing miracle regardless of their word length.

That would be astonishing if C++ was defined in terms of the abstract
machine -- because then seemingly the definition of the abstract
machine itself would be nowhere to be found (searching the standard for
"Vienna" or something like that would not yield any results, I think).

Happily it's not the case that C++ is defined in terms of an abstract
machine.

The C++ standard defines the effects of execution of a C++ program /as/
an abstract machine, i.e., the abstract machine is the effect of a C++
program as per the rules for C++ programs. Sort of the other way from
being defined in terms of. Which in particular means that statements in
the standard about the effect of any construct should not be interpreted
as the effect within some abstract machine (which would yield an
infinitely recursive and impotent definition); instead it is directly
the effect of the construct, and that /is/ the abstract machine.

And the effects of various C++ constructs (and thereby, of the abstract
machine, which is sum total of such effects) have been very carefully
crafted to correspond to and be efficient on actual machines.

C++, and C, are practical engineers' languages.

My bad. The remark was meant as a joke, but I forgot to end the sentence
with appropriate smiley punctuation.


Best

Kai-Uwe Bux

 

[SasQ]

Dnia Sat, 24 Mar 2007 21:18:29 -0400, Kai-Uwe Bux napisa³(a):

You are right in that long int has at least 32 bits.
But I don't see how this implies anything about what
C++ is designed for.

Because I don't know how to apply this rule of Standard
to 8-bit or 16-bit machines.

Is that a question about the availability of C++ compilers
for those platforms?

No, it's the question about possibility to implement
Standard rules for those platforms which don't have
32-bit registers to stuff 'long int' into them.

Yes, that would be the way to go.

Huh.. OK... And are there any other ways?

Or maybe by dropping out the 'long int' type?
[but is it still standard-complaint then?]

That would not be standard compliant.

OK, one down... ;J

 

[SasQ]

Dnia Sun, 25 Mar 2007 03:07:46 +0200, Alf P. Steinbach napisa³(a):

'long int' has to be at least 32 bits.

OK, thanks for assuring me for this rule of Standard.
But I still don't know how could it be possible to apply
that rule for platforms which are less than 32-bit and
don't have 32-bit registers to fit 'long int'.

Yes.

Good How? :>

Using a compiler for that platform, or perhaps
a cross-compiler.

It's a circumlocutive answer ;P
I'm rather interested in how to make that sizeof(long int)
would give 4 on a 8-bit or 16-bit platform.
The particular compiler would be a good example, but I can't
find any standard-complaint 8-bit nor 16-bit compiler.

Yes.

Good to know. It's always one step further than nothing... :J

Or maybe by dropping out the 'long int' type? [but is it still
standard-complaint then?]

No, it wouldn't be standard-compliant by dropping 'long int',
but the C++ standard differentiates between "hosted" and
"free-standing" implementations, the latter being meant
primarily for embedded work, allowed to drop (not offer)
most of the standard library.

Yes, I know. I've seen that kind of stuff in a chapter about
the main() function requirements [some people even have told me
that Windows is an embedded/freestanding environment because of
using nonstandard WinMain() function ].
But I don't see anything about that in the chapter about
built-in types. And not every 16-bit machine is "embedded" ;J

 

[red floyd]

Dnia Sun, 25 Mar 2007 03:07:46 +0200, Alf P. Steinbach napisa³(a):


OK, thanks for assuring me for this rule of Standard.
But I still don't know how could it be possible to apply
that rule for platforms which are less than 32-bit and
don't have 32-bit registers to fit 'long int'.

Software emulation. Same way that C compilers for 8 bit machines
emulated 32-bits (Ah, the good old Z-80!).

 

[=?ISO-8859-15?Q?Juli=E1n?= Albo]

Because I don't know how to apply this rule of Standard
to 8-bit or 16-bit machines.

The way to apply it is very simple. Just say: "In 8 or 16 bit machines a
long int has at least 32 bits".

No, it's the question about possibility to implement
Standard rules for those platforms which don't have
32-bit registers to stuff 'long int' into them.

The same way the floating point format rules are implemented in machines
that don't have floating point in the cpu or in a coprocessor. By designing
rules and writing code.

 

[SasQ]

Dnia Sun, 25 Mar 2007 01:57:59 +0100, SasQ napisa³(a):

Thanks for everyone for their explanations.
It has cleared me a couple of things.
Now I'll try to sumarize it:

Machine word: sizeof(long int):
8-bit 4 Emulated as four 8-bit registers.
16-bit 4 Emulated as two 16-bit registers.
32-bit 4 Doesn't have to be emulated.
64-bit 4 or 8? Doesn't have to be emulated.

Now I have doubts only on 64-bit machines, where 'long int'
may be that 'at least 32 bits', but it can be more also
So if it can, sould it or not?

Next, we have 'short int', which the Standard requires to be
at least 16 bits. So, let's look:

Machine word: sizeof(short int):
8-bit 2 Emulated as two 8-bit registers
16-bit 2 Doesn't have to be emulated.
32-bit 2 Doesn't have to be emulated.
64-bit 2 Doesn't have to be emulated.

Here, I have some doubts on 64-bit platform. On 32-bit
'short' is mostly 16-bit and no more, because it should be
able to be shorter than plain 'int'. On 64-bit platforms
it could be more, if plain 'int' were 64-bit. But I don't
know how it is there, and I've seen only one particular
case, where plain 'int' has still 32 bits, so the 'short
int' has to be 16-bit.

And now we come to plain 'int' type
The Standard requires it to be at least as much as 'short int',
and defines it as the type most convenient for integer arithmetics
on the particular platform. So, if we apply the same rules as
for 'long int' [with the emulation], we would get:

Machine word: sizeof(int):
8-bit 2?? Emulated as two 8-bit registers??
16-bit 2 Doesn't have to be emulated.
32-bit 4 Doesn't have to be emulated.
64-bit 4 or 8? Doesn't have to be emulated.

I don't think emulating 'int' as two 8-bit registers to be
the most convenient for the 8-bit platform to compute on
integers Even if 16-bit platforms could emulate C++
Standard rules and feel good with it, for 8-bit machines
there is something wrong, I think. Something, that was
missed by the creators of Standard, or [more probably ]
by me :/ So what is the thing I am missing here?

I think I know the theory [C++ Standard] but I don't know
how to apply it in practice.

 

[James Kanze]

Dnia Sun, 25 Mar 2007 01:57:59 +0100, SasQ napisa³(a):

Thanks for everyone for their explanations. It has cleared me
a couple of things. Now I'll try to sumarize it:

Machine word: sizeof(long int):
8-bit 4 Emulated as four 8-bit registers.
16-bit 4 Emulated as two 16-bit registers.
32-bit 4 Doesn't have to be emulated.
64-bit 4 or 8? Doesn't have to be emulated.

You're still limiting yourself too much. C++ has nothing to say
about the size of a machine word. All it guarantees is that
char has at least 8 bits (but there have been implementations
with 9, 10 and 32 bit chars, at least), that int is at least 16
bits (I've seen 16, 32, 36 and 48---and 24 wouldn't surprise me
for some machines I've heard of), that long is at least 32 bits,
and the next standard will also require a long long of at least
64 bits.

In addition, you are guaranteed that the size of any type is a
positive integral value, and that:

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

Note that if char is 32 bits, all of the integral types can have
a size of 1.

Now I have doubts only on 64-bit machines, where 'long int'
may be that 'at least 32 bits', but it can be more also
So if it can, sould it or not?

All of the 64 bit machines I use have a 64 bit long. It seems
the most natural.

Next, we have 'short int', which the Standard requires to be
at least 16 bits. So, let's look:

Machine word: sizeof(short int):
8-bit 2 Emulated as two 8-bit registers
16-bit 2 Doesn't have to be emulated.
32-bit 2 Doesn't have to be emulated.
64-bit 2 Doesn't have to be emulated.

Here, I have some doubts on 64-bit platform. On 32-bit
'short' is mostly 16-bit and no more, because it should be
able to be shorter than plain 'int'.

That's not required. On word addressed machines (e.g. Unisys
2200), it's probably the same as int. In fact, on a Unisys
2200, I would expect short, int and long all to have 36 bits.

On 64-bit platforms
it could be more, if plain 'int' were 64-bit. But I don't
know how it is there, and I've seen only one particular
case, where plain 'int' has still 32 bits, so the 'short
int' has to be 16-bit.

There's no "has to" about it. In practice, on a byte addressed
64 bit machine, the vendor will probably want to offer access to
all natively supported lengths. Since there are four, and there
are only four integral types, there is only one solution.

And now we come to plain 'int' type
The Standard requires it to be at least as much as 'short int',
and defines it as the type most convenient for integer arithmetics
on the particular platform. So, if we apply the same rules as
for 'long int' [with the emulation], we would get:

Machine word: sizeof(int):
8-bit 2?? Emulated as two 8-bit registers??
16-bit 2 Doesn't have to be emulated.
32-bit 4 Doesn't have to be emulated.
64-bit 4 or 8? Doesn't have to be emulated.

I don't think emulating 'int' as two 8-bit registers to be
the most convenient for the 8-bit platform to compute on
integers

It's more convenient that using even more bytes, and it is the
least the standard allows.

Even if 16-bit platforms could emulate C++
Standard rules and feel good with it, for 8-bit machines
there is something wrong, I think. Something, that was
missed by the creators of Standard, or [more probably ]
by me :/ So what is the thing I am missing here?

That people wanted C to be useful, and so defined a generally
useful set of rules for the period. (One could easily argue
today that an int should be required to be at least 32 bits.)
C++ just took over these rules.

I think I know the theory [C++ Standard] but I don't know
how to apply it in practice.

You apply it in practice by first deciding what your goals are.
If you're code targets desktop computers or larger, for example,
it's perfectly reasonable to assume that an int is at least 32
bits. If your code makes extensive use of the Windows API, for
its GUI, you might as well assume that int is 32 bits, and 2's
complement to boot. If you think that your code might have to
run on embedded systems, or on mainframes, or legacy systems,
then you'll have to be a lot more careful. Still, for most
code, all you have to worry about is the maximum and minimum
values you need to handle.

 

[SasQ]

Dnia Thu, 29 Mar 2007 02:44:27 -0700, James Kanze napisa³(a):

C++ has nothing to say about the size of a machine word.
All it guarantees is that char has at least 8 bits
(but there have been implementations with 9, 10 and 32 bit
chars, at least), that int is at least 16 bits
(I've seen 16, 32, 36 and 48---and 24 wouldn't surprise me
for some machines I've heard of), that long is at least 32
bits, and the next standard will also require a long long of
at least 64 bits.

Is it sure for now?
Would there be 'long long long int' in a future then?

And where do you know that from? I had problems with obtaining
a copy of C++ Standard document [it isn't available for free in
the Internet in a way W3C standards do, so I had to borrow a copy
from a friend], and the more for obtaining any information about
the new C++0x Standard plans.

In addition, you are guaranteed that the size of any type is a
positive integral value

Good to know that it wouldn't be negative or a fraction
I haven't seen any negative size in my life yet ))

and that:

sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long)

Yeah, that's what I've known before.

Note that if char is 32 bits, all of the integral types can have
a size of 1.

Interesting note.

All of the 64 bit machines I use have a 64 bit long.
It seems the most natural.

For me too. But probably not for Microsoft: they use 32 bits
for 'long int' on 64-bit architecture and use nonstandard
[not for today version of C++ Standard] 'long long int' for
64-bit integers in their compiler.
I know the Standard doesn't require 'long int' to be the
maximal size on a particular platform, so the 32-bit 'long int'
is acceptable [thus stupid, for me]. But using 'long long int'
for 64 bits and showing a finger to Standards when it's possible
to use 'long int' for that, it's a mess IMHO.

That's not required. On word addressed machines (e.g. Unisys
2200), it's probably the same as int. In fact, on a Unisys
2200, I would expect short, int and long all to have 36 bits.

Yes, I've thought '<=' but said '<' ;P My bad.

It's more convenient that using even more bytes, and it is the
least the standard allows.

OK, I've found the following example:
http://www.z88dk.org/old/zcc.html#compdatat
and it explained me a lot.
Seems like the "emulation" is the way to go to implement the
rules of Standard in practice, on non-32-bit platforms.

 

[=?iso-8859-1?q?Erik_Wikstr=F6m?=]

Dnia Thu, 29 Mar 2007 02:44:27 -0700, James Kanze napisa³(a):


Is it sure for now?
Would there be 'long long long int' in a future then?

You can get a copy of the working document for the next standard from
the C++ Standard Committee's page [1]. There you can also get to read
the proposals for new features and other information. If you does not
have the standard available you can always try to get a copy of the
draft closest to the standard.

Anyway, on this neat little list [2] you can see that the long long
type is part of the current working document and will thus be in the
next standard.

1. http://www.open-std.org/jtc1/sc22/wg21/
2. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2122.htm

 

[James Kanze]

Dnia Thu, 29 Mar 2007 02:44:27 -0700, James Kanze napisa³(a):

Is it sure for now?

About as sure as anything can be. C99 has it. C++ adopted it,
partially at least on the grounds of C compatibility. Formally,
the next version of the standard hasn't been adopted, and the
committee could vote to remove it. Practically, I'd say that
the probability of that happening is about as close to 0 as you
can get.

Would there be 'long long long int' in a future then?

I doubt it. The C committee adopted long long because it was
already in wide-spread use. They recognized, however, that long
long was not the right solution, because it doesn't scale, so
they also provided a more generic solution for future expansion
(which has also been adopted by the committee).

And where do you know that from?

I'm a technical expert with the French national body (AFNOR),
and participate in the standardization effort.

[...]

For me too. But probably not for Microsoft: they use 32 bits
for 'long int' on 64-bit architecture and use nonstandard
[not for today version of C++ Standard] 'long long int' for
64-bit integers in their compiler.

Every C++ compiler I know accepts long long today. It is part
of the C standard, after all.

I know the Standard doesn't require 'long int' to be the
maximal size on a particular platform,

It requires long to be the largest integral size.

This lead to extensive debate in the C committee. There is a
lot of C code out there doing things like:
size_t s ;
printf( "%lu", (unsigned long)s ) ;
unsigned long is used, of course, because it was guaranteed that
no larger integral type existed.

The adoptation of long long broke such code. The C committee
was not happy about that, but felt, in the end, that they didn't
have much choice.

In the next version of the C++ standard, there will be no
requirement that long (or even long long) be the largest
integral type available. A system with 128 bit words could
still define long long to be a 64 bit type, and define a
int128_t as well. In the future, if you want the largest
integral type available, you will have to use intmax_t (defined
in <stdint.h>, and in C++ <cstdint>). To write something like
the above, you would have to include <stdint.h> and <inttype.h>,
and write:
size_t s ;
printf( "%ju", (uintmax_t)s ) ;
or:
size_t s ;
printf( "%zu", s ) ;

so the 32-bit 'long int'
is acceptable [thus stupid, for me]. But using 'long long int'
for 64 bits and showing a finger to Standards when it's possible
to use 'long int' for that, it's a mess IMHO.

I don't think it a particularly wise decision either. But
vendors don't like to break user code, even when it is already
"broken"; presumably, they fear that there is some user code
which depends on long being 32 bits.