data type of size 64 bits on a 32 bit processor

[junky_fellow]

Hi,

I am using a gcc compiler for a 32 bit powerpc processor. When I
look at the size of unsigned long long, it displays 8 bytes. I was
wondering, how we can have a data type of 64 bits on a 32 bit
processor ? Is there some problem with my compiler ?

thanks for any help ...

 

[Tim Prince]

Hi,

I am using a gcc compiler for a 32 bit powerpc processor. When I
look at the size of unsigned long long, it displays 8 bytes. I was
wondering, how we can have a data type of 64 bits on a 32 bit
processor ? Is there some problem with my compiler ?

Compilers implement wider types by coupling together shorter native data
types where necessary. How do you think C got off the ground in the
days of 8-bit computing?

 

[ziibrs]

As in C99:

long long and its unsigned counterpart unsigned long long are new
types in C99. A long long variable shall have at least 64 bits.

there is a long double with 96bits that also exists on 32bit machines

in fact the xx-bit architecture does very little to do with variable
sizes ( of course it is ment to be that int is as long as the memory
address), because when storing variable in registers u can use more
than one. I am not a specialist in hardware but as i understand in
fact we have one long register that emulates smaller ones. And if wee
need we can emuleate a 64-bit or even lager register to store data in.

 

[Chris Dollin]

I am using a gcc compiler for a 32 bit powerpc processor. When I
look at the size of unsigned long long, it displays 8 bytes. I was
wondering, how we can have a data type of 64 bits on a 32 bit
processor ?

Two words at a time.

Is there some problem with my compiler ?

Not in this respect.

 

[Kenneth Brody]

Hi,

I am using a gcc compiler for a 32 bit powerpc processor. When I
look at the size of unsigned long long, it displays 8 bytes. I was
wondering, how we can have a data type of 64 bits on a 32 bit
processor ? Is there some problem with my compiler ?

What makes you think there is a "problem"? Just because a particular
piece of hardware doesn't natively support N-bit integers doesn't
mean the compiler can't supply software routines to handle them.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Mark McIntyre]

Hi,

I am using a gcc compiler for a 32 bit powerpc processor. When I
look at the size of unsigned long long, it displays 8 bytes. I was
wondering, how we can have a data type of 64 bits on a 32 bit
processor ?

This isn't a C question.

<OT>
The width of the bus only restricts the amount of addressable space,
not the size an object can be.

For more info, read any history book about computing.
</OT>
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Malcolm McLean]

I am using a gcc compiler for a 32 bit powerpc processor. When I
look at the size of unsigned long long, it displays 8 bytes. I was
wondering, how we can have a data type of 64 bits on a 32 bit
processor ? Is there some problem with my compiler ?

thanks for any help ...

Try the following

register long long x;

if the compiler claims to be able to store x in a register then I think
you'd have legitimate grounds for complaint.

 

[Ben Pfaff]

I am using a gcc compiler for a 32 bit powerpc processor. When I
look at the size of unsigned long long, it displays 8 bytes. I was
wondering, how we can have a data type of 64 bits on a 32 bit
processor ? Is there some problem with my compiler ?

How do you do arithmetic by hand on numbers with more than one
digit? The computer can do multi-word arithmetic the same way.

 

[Ben Pfaff]

Try the following

register long long x;

if the compiler claims to be able to store x in a register then I
think you'd have legitimate grounds for complaint.

Um, why?

 

[Kenneth Brody]

<[email protected]> wrote in message

[... How can "long long" be 64 bits in a 32-bit CPU? ...]

Try the following

register long long x;

if the compiler claims to be able to store x in a register then I think
you'd have legitimate grounds for complaint.

Why? The only thing "register" guarantees is that you can't take
the address of the object. The following definition "works" just
fine on my compiler, even with warnings turned to max:

register char foo[32766];

Unfortunately, it's not very useful, as strcpy() and printf() can't
get foo passed as an argument. I get an error "'&' on register
variable". In fact, even "foo[0] = 'x'" gives that error.

So, what can one do with a register array?

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Keith Thompson]

Try the following

register long long x;

if the compiler claims to be able to store x in a register then I
think you'd have legitimate grounds for complaint.

If the compiler accepts that declaration without complaint, that
doesn't mean that the compiler claims to be able to store x in a
register. The "register" keyword merely "suggests that access to the
object be as fast as possible" (C99 6.7.1p4). The compiler could
silently ignore the "register" keyword (except that it must diagnose
any attempt to compute x's address).

Even if, for example, long long is 64 bits and CPU registers are 32
bits, a compiler could plausibly store x in two registers.

 

[Ian Collins]

If the compiler accepts that declaration without complaint, that
doesn't mean that the compiler claims to be able to store x in a
register. The "register" keyword merely "suggests that access to the
object be as fast as possible" (C99 6.7.1p4). The compiler could
silently ignore the "register" keyword (except that it must diagnose
any attempt to compute x's address).

Even if, for example, long long is 64 bits and CPU registers are 32
bits, a compiler could plausibly store x in two registers.

Which is what happened on 16 bit x86 processors with 32 bit longs.

 

[J. J. Farrell]

Try the following

register long long x;

if the compiler claims to be able to store x in a register then I think
you'd have legitimate grounds for complaint.

Indeed, but how would it go about claiming that? There's no way in C
for it to do so since C knows nothing about machine registers. All the
register keyword means in C is that you can't use the address operator
on an object with register storage class.

 

[Jack Klein]

As in C99:

long long and its unsigned counterpart unsigned long long are new
types in C99. A long long variable shall have at least 64 bits.

there is a long double with 96bits that also exists on 32bit machines

Really? Can you tell me where to find it on an ARM11? How about on a
Cell processor?

For that matter, I'd like to see you find one on any x86, 16-bit,
32-bit, or 64-bit. Keep looking until you find it, we'll wait.

 

[Jack Klein]

This isn't a C question.

<OT>
The width of the bus only restricts the amount of addressable space,
not the size an object can be.

The width of which bus? The size of the address space is not
necessarily, and quite frequently not actually, related to the data
bus width.

Simple example, the Intel 8088 could access 1,048,576 octets of memory
with an 8-bit data bus. The Intel 8086 could access 1,048,576 octets
of memory with a 16-bit data bus.

 

[Jack Klein]

How do you do arithmetic by hand on numbers with more than one
digit? The computer can do multi-word arithmetic the same way.

Often incorrectly. That's why I program computers to do it for me.

 

[user923005]

Try the following

register long long x;

if the compiler claims to be able to store x in a register then I think
you'd have legitimate grounds for complaint.

The register keyword is only a suggestion. The compiler is free to
ignore it.
Now, if you take the address of x later on, then the compiler is
forced to complain about it.

 

[jaysome]

As in C99:

long long and its unsigned counterpart unsigned long long are new
types in C99. A long long variable shall have at least 64 bits.

there is a long double with 96bits that also exists on 32bit machines

Where did you get that notion?

Microsoft Visual Studio 6 and Visual Studio 2005 use the same
representation (8 bytes, 64 bits) for types double and long double,
even though they could do better with long double and support the
80-bit extended precision type of the Intel FPU (which gcc supports).
See

http://support.microsoft.com/default.aspx?scid=kb;en-us;129209

for Microsoft's explanation.

 

[Dave Vandervies]

The register keyword is only a suggestion. The compiler is free to
ignore it.
Now, if you take the address of x later on, then the compiler is
forced to complain about it.

Nitpick: I don't think that's exactly true (though that is the intent
of that particular constraint).

Taking the address of a register-qualified variable is a constraint
violation, but an implementation that issues a warning on seeing the
"register" keyword:
--------
foo.c: line 42: Warning: Ignoring "register" keyword (I trust my judgement
on register allocation more than yours)
--------
has issued the required diagnostic and is under no obligation to complain
if its address is later taken.


dave

 

[Ben Pfaff]

The only thing "register" guarantees is that you can't take
the address of the object. The following definition "works" just
fine on my compiler, even with warnings turned to max:

register char foo[32766];

There are serious pitfalls in trying to use an array with
register class. See 6.3.2.1p3 (in C99). The last sentence is
the important part:

Except when it is the operand of the sizeof operator or the
unary & operator, or is a string literal used to initialize
an array, an expression that has type ``array of type'' is
converted to an expression with type ``pointer to type''
that points to the initial element of the array object and
is not an lvalue. If the array object has register storage
class, the behavior is undefined.