128 bit signed and unsigned integer types
Andrei Alexandrescu
SeeWebsiteForEmail at erdani.org
Sun Dec 28 11:47:40 PST 2008
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
More information about the Digitalmars-d
mailing list