128 bit signed and unsigned integer types

[Yigal Chripun]

Andrei Alexandrescu wrote:
> Yigal Chripun wrote:
>> Andrei Alexandrescu wrote:
>>> dsimcha wrote:
>>>> == Quote from Andrei Alexandrescu (SeeWebsiteForEmail at erdani.org)'s
>>>> article
>>>>> Walter Bright wrote:
>>>>>> John Reimer wrote:
>>>>>>> Hello Walter,
>>>>>>>
>>>>>>>> You know, the unimplemented 128 bit integer types.
>>>>>>>>
>>>>>>>> Does anyone have a use for these?
>>>>>>>>
>>>>>>>
>>>>>>> Was that "cent" and "ucent"?
>>>>>> yes.
>>>>>>
>>>>>>> Would any of these map well to SSE Instructions on Intel CPU's?
>>>>>> Not a chance :-(
>>>>> Then it looks like we better leave large fixed-size integers to a
>>>>> library.
>>>>> Andrei
>>>>
>>>> Something that I still don't think has been made very clear in this
>>>> discussion
>>>> that I'm very curious about: How efficient would these large
>>>> fixed-size ints be
>>>> (on 32-bit hardware)? Would they be almost as fast as 64-bit, almost
>>>> as slow as
>>>> bigints, or somewhere roughly in the middle? Obviously on 64-bit
>>>> hardware they
>>>> can be made fast, but if that's the only place they can be made fast,
>>>> then I think
>>>> it's more important that DMD support 64-bit hardware first.
>>>
>>> Assume we define a FixedInt(uint bits) structure. That would contain the
>>> value in-situ so there is no dynamic allocation, no indirection, and
>>> full-blown copying. For built-in sizes, FixedInt will alias itself away,
>>> for example:
>>>
>>> template FixedInt(uint n) if (n == 8) { alias byte FixedInt; }
>>> template FixedInt(uint n) if (n == 16) { alias short FixedInt; }
>>> template FixedInt(uint n) if (n == 32) { alias int FixedInt; }
>>> template FixedInt(uint n) if (n == 64) { alias long FixedInt; }
>>>
>>> That's nice because it allows you to use FixedInt with a parameterized
>>> size throughout, yet still take advantage of builtin optimizations
>>> whenever applicable.
>>>
>>> For the larger sizes and operations my guess would be that FixedInt will
>>> be close to what can be achieved via built-ins.
>>>
>>>
>>> Andrei
>>
>> is it possible to make int/long/short/etc internal to the compiler and
>> use the above FixedInt in the language? there shouldn't be any
>> performance differences between an old-style int and the above
>> FixedInt!(32), for instance.
>> this way all the different types are reduced to one built-in type that
>> looks like a template. similar to the way C++ uses the template syntax
>> for casts like static_cast<type>(var) even though it's usually
>> implemented inside the compiler.
>
> Well it's possible but probably too verbose for many. I mean, if I had
> only FixedInt, I'd first define int, short et al as aliases :o).
>
> Andrei

Obviously such a solution needs a shorter name to be useful.
many languages use "Integer" as the name of the type.
I agree that C's "int" is probably the shortest, but using anything 
like: int!(4) to define a 4-byte int or an int!(32) if your prefer bits 
isn't that much longer.

having int!(WORD) or something like that to denote a size_t or even just 
alias it as "word" is also nice and much better than C style whatever_t 
typedefs.
also, isn't it better design to have just *one* generalized type and one 
keyword and allowing the user to alias it however he wants and/or 
provide aliases in a stdlib module rather than the other way around? if 
nothing else than from a minimalist POV and eliminating unneeded stuff 
from the language?

Also, I wonder what's the usage percentage for these keywords. how 
frequently do people actually use short/long instead of just int?