Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > integral types

Reply
Thread Tools

integral types

 
 
SasQ
Guest
Posts: n/a
 
      03-24-2007
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?]

--
SasQ
 
Reply With Quote
 
 
 
 
Alf P. Steinbach
Guest
Posts: n/a
 
      03-25-2007
* 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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
 
 
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      03-25-2007
SasQ wrote:

> 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
 
Reply With Quote
 
Alf P. Steinbach
Guest
Posts: n/a
 
      03-25-2007
* Kai-Uwe Bux:
> SasQ wrote:
>
>> 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.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
 
Reply With Quote
 
Kai-Uwe Bux
Guest
Posts: n/a
 
      03-25-2007
Alf P. Steinbach wrote:

> * Kai-Uwe Bux:
>> SasQ wrote:
>>
>>> 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
 
Reply With Quote
 
SasQ
Guest
Posts: n/a
 
      03-28-2007
Dnia Sat, 24 Mar 2007 21:18:29 -0400, Kai-Uwe Bux napisał(a):

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


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

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


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.

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


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
 
Reply With Quote
 
SasQ
Guest
Posts: n/a
 
      03-28-2007
Dnia Sun, 25 Mar 2007 03:07:46 +0200, Alf P. Steinbach napisał(a):

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


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

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

>
> Yes.


Good How? :>

>> If yes, how can it be done?

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

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

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

--
SasQ
 
Reply With Quote
 
red floyd
Guest
Posts: n/a
 
      03-28-2007
SasQ wrote:
> Dnia Sun, 25 Mar 2007 03:07:46 +0200, Alf P. Steinbach napisał(a):
>
>>> 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.

>
> 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!).
 
Reply With Quote
 
=?ISO-8859-15?Q?Juli=E1n?= Albo
Guest
Posts: n/a
 
      03-28-2007
SasQ wrote:

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


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.

--
Salu2
 
Reply With Quote
 
SasQ
Guest
Posts: n/a
 
      03-29-2007
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.

--
SasQ
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C++ 42 11-04-2008 12:39 PM
C/C++ language proposal: Change the 'case expression' from "integral constant-expression" to "integral expression" Adem C Programming 45 11-04-2008 12:39 PM
Can "all bits zero" be a trap representation for integral types? Army1987 C Programming 6 07-07-2007 12:01 PM
size and nomenclature of integral types Shailesh C++ 4 04-04-2004 06:37 AM
sizeof C integral types ark C Programming 45 01-19-2004 05:16 PM



Advertisments