Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > 64-bit integers where the implementation supports max 32-bit ints

Reply
Thread Tools

64-bit integers where the implementation supports max 32-bit ints

 
 
Ian Collins
Guest
Posts: n/a
 
      08-07-2013
Keith Thompson wrote:
> Malcolm McLean <(E-Mail Removed)> writes:
>> On Tuesday, August 6, 2013 3:12:47 PM UTC+1, James Harris wrote:
>>> "James Kuyper" <(E-Mail Removed)> wrote in message
>>>
>>> sizeof sint_t 8
>>>
>>> sizeof uint_t 8
>>>
>>> The above set is for the 64-bit target which is why [su]int_t have size 8.
>>> (I believe gcc defaults to 4 byte ints on 64-bit targets.)
>>>

>> int should be the natural register size, which means 64 bits on a 64 bit
>> system. That also means that, expect for the annoying but practically
>> unimportant case of a byte array that takes up over half the memory,
>> int can index any array.

>
> Perhaps it "should". Nevertheless, int is typically 32 bits on 64-bit
> systems, probably because making it 64 bits would mean you can't have
> both a 16-bit type and a 32-bit type (unless the implementation resorts
> to extended integer types).


More likely a mixture of too much fragile code that assumes 32 bit int
and more importantly for new code, performance.

--
Ian Collins
 
Reply With Quote
 
 
 
 
James Harris
Guest
Posts: n/a
 
      08-07-2013

"Stephen Sprunk" <(E-Mail Removed)> wrote in message
news:ktsch0$c9e$(E-Mail Removed)...
> On 06-Aug-13 09:19, Malcolm McLean wrote:
>> On Tuesday, August 6, 2013 3:12:47 PM UTC+1, James Harris wrote:
>>> sizeof sint_t 8
>>> sizeof uint_t 8
>>>
>>> The above set is for the 64-bit target which is why [su]int_t have
>>> size 8. (I believe gcc defaults to 4 byte ints on 64-bit targets.)

>>
>> int should be the natural register size, which means 64 bits on a 64
>> bit system.

>
> Of course, that assumes a useful definition of "natural". For instance,
> there are three common models for "64-bit" machines: ILP64, I32LP64 and
> IL32LLP64. And proponents of each will explain why their model is more
> "natural" than the others.


I'm not familiar with the notation but taking a guess that they mean

ILP64 - int, long and pointers all 64 bit
I32LP64 - int 32, long and pointers 64
IL32LLP64 - int and long 32, long long and pointers 64

>> That also means that, expect for the annoying but practically
>> unimportant case of a byte array that takes up over half the memory,
>> int can index any array.

>
> That assumes an int is as wide as a void*, which is not true on I32LP64
> and IL32LLP64 systems, e.g. Linux and Windows on x86-64.


Is there a type that should be used as index of a potentially very large
array? size_t? ptrdiff_t? unsigned long long?

James


 
Reply With Quote
 
 
 
 
Stephen Sprunk
Guest
Posts: n/a
 
      08-07-2013
On 07-Aug-13 05:11, James Harris wrote:
> "Stephen Sprunk" <(E-Mail Removed)> wrote in message
> news:ktsch0$c9e$(E-Mail Removed)...
>> On 06-Aug-13 09:19, Malcolm McLean wrote:
>>> int should be the natural register size, which means 64 bits on a
>>> 64 bit system.

>>
>> Of course, that assumes a useful definition of "natural". For
>> instance, there are three common models for "64-bit" machines:
>> ILP64, I32LP64 and IL32LLP64. And proponents of each will explain
>> why their model is more "natural" than the others.

>
> I'm not familiar with the notation but taking a guess that they mean
>
> ILP64 - int, long and pointers all 64 bit I32LP64 - int 32, long and
> pointers 64 IL32LLP64 - int and long 32, long long and pointers 64


Exactly.

>>> That also means that, expect for the annoying but practically
>>> unimportant case of a byte array that takes up over half the
>>> memory, int can index any array.

>>
>> That assumes an int is as wide as a void*, which is not true on
>> I32LP64 and IL32LLP64 systems, e.g. Linux and Windows on x86-64.

>
> Is there a type that should be used as index of a potentially very
> large array? size_t? ptrdiff_t? unsigned long long?


While theoretically possible, it's unlikely that any implementation is
capable of creating an object (including an array) larger than size_t
can count.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      08-07-2013
On Wednesday, August 7, 2013 3:48:00 AM UTC+1, Stephen Sprunk wrote:
> On 06-Aug-13 09:19, Malcolm McLean wrote:
>
> > That also means that, expect for the annoying but practically
> > unimportant case of a byte array that takes up over half the memory,
> > int can index any array.

>
> That assumes an int is as wide as a void*, which is not true on I32LP64
> and IL32LLP64 systems, e.g. Linux and Windows on x86-64.
>

The alternative is to patch the compiler so that objects greater
than 2MB in size can't be created. For the vast majority of programs,that
won't be a problem. However if someone does have a machine with a massive
memory, they'll expect to be able to declare massive flat array, so it's
not psychologically a good solution.
 
Reply With Quote
 
Rosario1903
Guest
Posts: n/a
 
      08-07-2013
On Wed, 7 Aug 2013 11:11:11 +0100, "James Harris" wrote:
>"Stephen Sprunk" <(E-Mail Removed)> wrote in message
>news:ktsch0$c9e$(E-Mail Removed)...
>> On 06-Aug-13 09:19, Malcolm McLean wrote:
>>> On Tuesday, August 6, 2013 3:12:47 PM UTC+1, James Harris wrote:
>>>> sizeof sint_t 8
>>>> sizeof uint_t 8
>>>>
>>>> The above set is for the 64-bit target which is why [su]int_t have
>>>> size 8. (I believe gcc defaults to 4 byte ints on 64-bit targets.)
>>>
>>> int should be the natural register size, which means 64 bits on a 64
>>> bit system.

>>
>> Of course, that assumes a useful definition of "natural". For instance,
>> there are three common models for "64-bit" machines: ILP64, I32LP64 and
>> IL32LLP64. And proponents of each will explain why their model is more
>> "natural" than the others.

>
>I'm not familiar with the notation but taking a guess that they mean
>
> ILP64 - int, long and pointers all 64 bit
> I32LP64 - int 32, long and pointers 64
> IL32LLP64 - int and long 32, long long and pointers 64


I32L32LL64P32LP64

>>> That also means that, expect for the annoying but practically
>>> unimportant case of a byte array that takes up over half the memory,
>>> int can index any array.

>>
>> That assumes an int is as wide as a void*, which is not true on I32LP64
>> and IL32LLP64 systems, e.g. Linux and Windows on x86-64.

>
>Is there a type that should be used as index of a potentially very large
>array? size_t? ptrdiff_t? unsigned long long?
>
>James

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-07-2013
"James Harris" <(E-Mail Removed)> writes:
[...]
> Is there a type that should be used as index of a potentially very large
> array? size_t? ptrdiff_t? unsigned long long?


size_t.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-07-2013
Rosario1903 <(E-Mail Removed)> writes:
> On Wed, 7 Aug 2013 11:11:11 +0100, "James Harris" wrote:

[...]
>>I'm not familiar with the notation but taking a guess that they mean
>>
>> ILP64 - int, long and pointers all 64 bit
>> I32LP64 - int 32, long and pointers 64
>> IL32LLP64 - int and long 32, long long and pointers 64

>
> I32L32LL64P32LP64


What?

The "I32L32" portion, if it's suppose to mean 32-bit int and 32-bit
long, is usually written "IL32".

Is "P32LP64" supposed to mean 32-bit pointers and 64-bit "long
pointers"? If so, what the heck is a "long pointer"?

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Rosario1903
Guest
Posts: n/a
 
      08-07-2013
On Wed, 07 Aug 2013 09:27:34 -0700, Keith Thompson wrote:

>Rosario1903 <(E-Mail Removed)> writes:
>> On Wed, 7 Aug 2013 11:11:11 +0100, "James Harris" wrote:

>[...]
>>>I'm not familiar with the notation but taking a guess that they mean
>>>
>>> ILP64 - int, long and pointers all 64 bit
>>> I32LP64 - int 32, long and pointers 64
>>> IL32LLP64 - int and long 32, long long and pointers 64

>>
>> I32L32LL64P32LP64

>
>What?
>
>The "I32L32" portion, if it's suppose to mean 32-bit int and 32-bit
>long, is usually written "IL32".
>
>Is "P32LP64" supposed to mean 32-bit pointers and 64-bit "long
>pointers"? If so, what the heck is a "long pointer"?


a pointer one have to use for see one film with len > 4GB
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-07-2013
Rosario1903 <(E-Mail Removed)> writes:
> On Wed, 07 Aug 2013 09:27:34 -0700, Keith Thompson wrote:
>>Rosario1903 <(E-Mail Removed)> writes:
>>> On Wed, 7 Aug 2013 11:11:11 +0100, "James Harris" wrote:

>>[...]
>>>>I'm not familiar with the notation but taking a guess that they mean
>>>>
>>>> ILP64 - int, long and pointers all 64 bit
>>>> I32LP64 - int 32, long and pointers 64
>>>> IL32LLP64 - int and long 32, long long and pointers 64
>>>
>>> I32L32LL64P32LP64

>>
>>What?
>>
>>The "I32L32" portion, if it's suppose to mean 32-bit int and 32-bit
>>long, is usually written "IL32".
>>
>>Is "P32LP64" supposed to mean 32-bit pointers and 64-bit "long
>>pointers"? If so, what the heck is a "long pointer"?

>
> a pointer one have to use for see one film with len > 4GB


Pointers point into (in-memory) objects, not into files.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Rosario1903
Guest
Posts: n/a
 
      08-07-2013
On Wed, 07 Aug 2013 18:36:28 +0200, Rosario1903
<(E-Mail Removed)> wrote:

>On Wed, 07 Aug 2013 09:27:34 -0700, Keith Thompson wrote:
>
>>Rosario1903 <(E-Mail Removed)> writes:
>>> On Wed, 7 Aug 2013 11:11:11 +0100, "James Harris" wrote:

>>[...]
>>>>I'm not familiar with the notation but taking a guess that they mean
>>>>
>>>> ILP64 - int, long and pointers all 64 bit
>>>> I32LP64 - int 32, long and pointers 64
>>>> IL32LLP64 - int and long 32, long long and pointers 64
>>>
>>> I32L32LL64P32LP64

>>
>>What?
>>
>>The "I32L32" portion, if it's suppose to mean 32-bit int and 32-bit
>>long, is usually written "IL32".
>>
>>Is "P32LP64" supposed to mean 32-bit pointers and 64-bit "long
>>pointers"? If so, what the heck is a "long pointer"?

>
>a pointer one have to use for see one film with len > 4GB


i think would be ok one cpu that has 2 kind of registers
one for 8 bit and one for 32 bit

the short 16 bit would be a composed type 2 8bit
with the usual big number routines for size 2
or would use the routine for 32 bit for doing operation on 16
the int and the long would be type 32 bit
the long long 64 bit would be type 2 32 bit
with the usual big number routines for array of size 2
the pointer would be 32 bit flat address space
and against the standard of C would be void*
the long pointer would be type 2 unsigned 2 complement 32 bit
with the usual big number routines for array of size 2
and something for dereference the flat 64 bit address
for example the simbol

u8,u16,u32,u64
all the other u2^n type could be in what i think write as array of
u32 and big number routines

operator for deference 64 bit number something as
u8 p, c;

p is a long pointer [64 bit that point to char]
so c=p would deference the pointer of 64 bit for obtain in its
position c...

all the same for what * means in C etc
u32 k;
u32 v=&k;
u8 p=(u8)&v;

possible i don't know what i wrote

for fpu i would do some test for see how is slow fixed point 64 bit
build on unsigned against float IEEE

 
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
The node.js Community is Quietly Changing the Face of Open Source Rodrick Brown Python 2 04-17-2013 04:47 PM
Is there a difference between the use of the word montage vscollage Danny D. Digital Photography 8 04-15-2013 02:24 PM
Windows 8 - so bad it's hastening the death of the PC? ~misfit~ NZ Computing 18 04-15-2013 04:15 AM
Iterator Question for map of ints to set of ints uclamathguy@gmail.com C++ 3 04-03-2005 03:26 AM
ints ints ints and ints Skybuck Flying C Programming 24 07-10-2004 04:48 AM



Advertisments