Integer conversions too pedantic in 64-bit

[Don]

spir wrote:
> On 02/17/2011 10:13 AM, Don wrote:
>> David Nadlinger wrote:
>>> On 2/17/11 8:56 AM, Denis Koroskin wrote:
>>>> I second that. word/uword are shorter than ssize_t/size_t and more in
>>>> line with other type names.
>>>>
>>>> I like it.
>>>
>>> I agree that size_t/ptrdiff_t are misnomers and I'd love to kill them 
>>> with
>>> fire, but when I read about »word«, I intuitively associated it with 
>>> »two
>>> bytes« first – blame Intel or whoever else, but the potential for 
>>> confusion
>>> is definitely not negligible.
>>>
>>> David
>>
>> Me too. A word is two bytes. Any other definition seems to be pretty 
>> useless.
>>
>> The whole concept of "machine word" seems very archaic and incorrect 
>> to me
>> anyway. It assumes that the data registers and address registers are 
>> the same
>> size, which is very often not true.
>> For example, on an 8-bit machine (eg, 6502 or Z80), the accumulator 
>> was only 8
>> bits, yet size_t was definitely 16 bits.
>> It's quite plausible that at some time in the future we'll get a 
>> machine with
>> 128-bit registers and data bus, but retaining the 64 bit address bus. 
>> So we
>> could get a size_t which is smaller than the machine word.
>>
>> In summary: size_t is not the machine word.
> 
> Right, there is no single native machine word size; but I guess what 
> we're interesting in is, from those sizes, the one that ensures minimal 
> processing time. I mean, the data size for which there are native 
> computation instructions (logical, numeric), so that if we use it we get 
> the least number of cycles for a given operation.

There's frequently more than one such size.

> Also, this size (on common modern architectures, at least) allows 
> directly accessing all of the memory address space; not a neglectable 
> property ;-).

This is not necessarily the same.

> Or are there points I'm overlooking?
> 
> Denis