Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #27489 > unrolled thread

Large number libraries/algorithms

Back to article view | Back to comp.lang.c

Contents

  Large number libraries/algorithms boltar2003@boltar.world - 2012-10-22 09:11 +0000
    Re: Large number libraries/algorithms Mark Bluemel <mark_bluemel@pobox.com> - 2012-10-22 10:15 +0100
    Re: Large number libraries/algorithms Heikki Kallasjoki <fis+usenet@zem.fi> - 2012-10-22 09:19 +0000
      Re: Large number libraries/algorithms boltar2003@boltar.world - 2012-10-22 09:40 +0000
    Re: Large number libraries/algorithms Noob <root@127.0.0.1> - 2012-10-22 11:24 +0200
    Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-22 13:29 +0200
      Re: Large number libraries/algorithms boltar2003@boltar.world - 2012-10-22 11:53 +0000
        Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-22 08:01 -0400
          Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-22 14:41 +0200
            Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-22 09:36 -0400
              Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-22 15:12 +0100
      Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-22 10:31 -0700
        Re: Large number libraries/algorithms Robert Wessel <robertwessel2@yahoo.com> - 2012-10-22 15:09 -0500
          Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-23 00:01 +0100
            Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-23 09:38 +0200
              Re: Large number libraries/algorithms Steve Thompson <stevet810@gmail.com> - 2012-10-23 12:40 +0000
                Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-23 16:23 +0200
                  Re: Large number libraries/algorithms Steve Thompson <stevet810@gmail.com> - 2012-10-23 14:38 +0000
              Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-23 12:58 -0700
                Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-24 09:01 +0200
                  Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-24 07:18 -0400
                    Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-24 14:23 +0200
                      Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-24 14:43 +0100
                        Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-24 11:33 -0700
                          Re: Large number libraries/algorithms Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-24 19:53 +0100
                      Re: Large number libraries/algorithms James Kuyper <jameskuyper@verizon.net> - 2012-10-24 10:50 -0400
                  Re: Large number libraries/algorithms Noob <root@localhost> - 2012-10-24 15:16 +0200
                    Re: Large number libraries/algorithms Noob <root@localhost> - 2012-10-24 18:57 +0200
                      Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-24 11:43 -0700
                        Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-25 09:05 +0200
    Re: Large number libraries/algorithms Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-22 08:23 -0400
      Re: Large number libraries/algorithms tom st denis <tom@iahu.ca> - 2012-10-22 11:40 -0700
        Re: Large number libraries/algorithms Keith Thompson <kst-u@mib.org> - 2012-10-22 17:05 -0700
          Re: Large number libraries/algorithms tom st denis <tom@iahu.ca> - 2012-10-23 07:10 -0700
    Re: Large number libraries/algorithms David Brown <david@westcontrol.removethisbit.com> - 2012-10-22 14:42 +0200
      Re: Large number libraries/algorithms Chad <cdalten@gmail.com> - 2012-10-23 14:39 -0700
    Re: Large number libraries/algorithms pete <pfiland@mindspring.com> - 2012-10-24 03:27 -0400

Page 1 of 2  [1] 2  Next page →

#27489 — Large number libraries/algorithms

Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on 
very large numbers (stored in char arrays presumably)? ie The sort of numbers 
that have no chance of fitting in even a 64 bit int or double. Or failing
that is there a good site explaining how to implement them yourself?

Thanks for any info

B2003

[toc] | [next] | [standalone]

#27490

On 22/10/2012 10:11, boltar2003@boltar.world wrote:
> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
> very large numbers (stored in char arrays presumably)? ie The sort of numbers
> that have no chance of fitting in even a 64 bit int or double. Or failing
> that is there a good site explaining how to implement them yourself?


A web search for "C bignum" is probably a good start.

[toc] | [prev] | [next] | [standalone]

#27491

On 2012-10-22, boltar2003@boltar.world <boltar2003@boltar.world> wrote:
> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on 
> very large numbers (stored in char arrays presumably)? ie The sort of numbers 
> that have no chance of fitting in even a 64 bit int or double. Or failing
> that is there a good site explaining how to implement them yourself?

The GNU Multiple Precision Arithmetic Library (GMP) is relatively
popular:

  http://gmplib.org/
  http://gmplib.org/manual/Integer-Functions.html


-- 
Heikki Kallasjoki

[toc] | [prev] | [next] | [standalone]

#27493

On Mon, 22 Oct 2012 09:19:52 GMT
Heikki Kallasjoki <fis+usenet@zem.fi> wrote:
>On 2012-10-22, boltar2003@boltar.world <boltar2003@boltar.world> wrote:
>> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on 
>> very large numbers (stored in char arrays presumably)? ie The sort of
>numbers 
>> that have no chance of fitting in even a 64 bit int or double. Or failing
>> that is there a good site explaining how to implement them yourself?
>
>The GNU Multiple Precision Arithmetic Library (GMP) is relatively
>popular:
>
>  http://gmplib.org/
>  http://gmplib.org/manual/Integer-Functions.html

Thanks, thats just what I need.

B2003

[toc] | [prev] | [next] | [standalone]

#27492

boltar2003 wrote:
> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
> very large numbers (stored in char arrays presumably)? ie The sort of numbers
> that have no chance of fitting in even a 64 bit int or double. Or failing
> that is there a good site explaining how to implement them yourself?

https://en.wikipedia.org/wiki/Arbitrary-precision_arithmetic

fefe's comparison:
http://dl.fefe.de/bignum.pdf

TomsFastMath:
http://libtom.org/?page=features&whatfile=tfm
https://github.com/libtom/tomsfastmath/raw/master/doc/tfm.pdf

Regards.

[toc] | [prev] | [next] | [standalone]

#27497

On 22/10/2012 11:11, boltar2003@boltar.world wrote:
> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
> very large numbers (stored in char arrays presumably)? ie The sort of numbers
> that have no chance of fitting in even a 64 bit int or double. Or failing
> that is there a good site explaining how to implement them yourself?
>
> Thanks for any info
>
> B2003
>

If your numbers will fit into 128-bit ints, then I think it is quite 
common to support 128-bit types in 64-bit compilers, and they will be 
much more efficient than arbitrarily long number libraries.  But that 
only helps if 128 bits is big enough.

[toc] | [prev] | [next] | [standalone]

#27499

On Mon, 22 Oct 2012 13:29:51 +0200
David Brown <david@westcontrol.removethisbit.com> wrote:
>On 22/10/2012 11:11, boltar2003@boltar.world wrote:
>> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
>> very large numbers (stored in char arrays presumably)? ie The sort of numbers
>> that have no chance of fitting in even a 64 bit int or double. Or failing
>> that is there a good site explaining how to implement them yourself?
>>
>> Thanks for any info
>>
>> B2003
>>
>
>If your numbers will fit into 128-bit ints, then I think it is quite 
>common to support 128-bit types in 64-bit compilers, and they will be 

I didn't know that. Whats the C type definition for 128 bit ints?

B2003

[toc] | [prev] | [next] | [standalone]

#27500

On 10/22/2012 07:53 AM, boltar2003@boltar.world wrote:
> On Mon, 22 Oct 2012 13:29:51 +0200
> David Brown <david@westcontrol.removethisbit.com> wrote:
...
>> If your numbers will fit into 128-bit ints, then I think it is quite 
>> common to support 128-bit types in 64-bit compilers, and they will be 
> 
> I didn't know that. Whats the C type definition for 128 bit ints?

[u]in128_t, [u]int_least128_t, [u]int_fast128_t. They're not guaranteed
to be supported, but those names are reserved for that use, and you can
check whether or not the corresponding macros in <stdint.h> are
#defined; they are not allowed to be #defined unless the corresponding
types are supported.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#27502

On 22/10/2012 14:01, James Kuyper wrote:
> On 10/22/2012 07:53 AM, boltar2003@boltar.world wrote:
>> On Mon, 22 Oct 2012 13:29:51 +0200
>> David Brown <david@westcontrol.removethisbit.com> wrote:
> ...
>>> If your numbers will fit into 128-bit ints, then I think it is quite
>>> common to support 128-bit types in 64-bit compilers, and they will be
>>
>> I didn't know that. Whats the C type definition for 128 bit ints?
>
> [u]in128_t, [u]int_least128_t, [u]int_fast128_t. They're not guaranteed
> to be supported, but those names are reserved for that use, and you can
> check whether or not the corresponding macros in <stdint.h> are
> #defined; they are not allowed to be #defined unless the corresponding
> types are supported.
>

I don't know whether these are necessarily supported by compilers (but 
if your compiler has them, then use them).  Other possibilities are 
__int128 (and unsigned __int128), or "long long int".


If you are happy moving to C++, you can probably also find class 
libraries that implement 128 bit integers and larger fixed-size integers 
(say, 256 bit).  Or you can make your own C functions reasonably easily.


Handling for non-native sizes of integers is probably going to be a lot 
less efficient than it could be (you need to use inline assembly to take 
advantage of carry flags, mixed precision multiplication, etc.), but it 
is going to be a lot more efficient than arbitrary precision libraries. 
  And if you can stick to 128-bit types supported by the compiler, then 
the code is going to be a lot easier to read and write.

Of course, that limits your code to integers of a particular size - and 
code efficiency may not be relevant for your purposes.

[toc] | [prev] | [next] | [standalone]

#27504

On 10/22/2012 08:41 AM, David Brown wrote:
> On 22/10/2012 14:01, James Kuyper wrote:
...
>> [u]in128_t, [u]int_least128_t, [u]int_fast128_t. They're not guaranteed
>> to be supported, but those names are reserved for that use, and you can
>> check whether or not the corresponding macros in <stdint.h> are
>> #defined; they are not allowed to be #defined unless the corresponding
>> types are supported.
>>
> 
> I don't know whether these are necessarily supported by compilers

I do. They aren't. I already said so above.

> ... (but 
> if your compiler has them, then use them).  Other possibilities are 
> __int128 (and unsigned __int128), or "long long int".

A conforming implementation of C90 can support long long only as an
extension. An implementation that conforms to either C99 or C2011, and
supports any 128-bit type (with no padding bits, and if signed, 2's
complement representation), has no excuse for not supporting the
corresponding <stdint.h> types. Therefore, looking for other names is
mainly needed only if you're using a C90 implementation that supports
128-bit types. I'm not sure how common those are - but I'd expect them
to be rare.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#27506

James Kuyper <jameskuyper@verizon.net> writes:

> On 10/22/2012 08:41 AM, David Brown wrote:
>> On 22/10/2012 14:01, James Kuyper wrote:
> ...
>>> [u]in128_t, [u]int_least128_t, [u]int_fast128_t. They're not guaranteed
>>> to be supported, but those names are reserved for that use, and you can
>>> check whether or not the corresponding macros in <stdint.h> are
>>> #defined; they are not allowed to be #defined unless the corresponding
>>> types are supported.
>>>
>> 
>> I don't know whether these are necessarily supported by compilers
>
> I do. They aren't. I already said so above.
>
>> ... (but 
>> if your compiler has them, then use them).  Other possibilities are 
>> __int128 (and unsigned __int128), or "long long int".
>
> A conforming implementation of C90 can support long long only as an
> extension. An implementation that conforms to either C99 or C2011, and
> supports any 128-bit type (with no padding bits, and if signed, 2's
> complement representation), has no excuse for not supporting the
> corresponding <stdint.h> types. Therefore, looking for other names is
> mainly needed only if you're using a C90 implementation that supports
> 128-bit types.

You also need to look for them for purely practical reasons.  For
example, with my gcc version, there is a 128-bit integer type meeting
all the right conditions but int128_t does not exist in c99 mode.  The
reason, I imagine, is that compiler and library development are somewhat
separate in gcc, so it's easier to keep stdint.h (and glibc's printf
family) at some sort of "lowest common denominator" level.

> I'm not sure how common those are - but I'd expect them
> to be rare.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27521

David Brown <david@westcontrol.removethisbit.com> writes:
> On 22/10/2012 11:11, boltar2003@boltar.world wrote:
>> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
>> very large numbers (stored in char arrays presumably)? ie The sort of numbers
>> that have no chance of fitting in even a 64 bit int or double. Or failing
>
> If your numbers will fit into 128-bit ints, then I think it is quite 
> common to support 128-bit types in 64-bit compilers, and they will be 
> much more efficient than arbitrarily long number libraries.  But that 
> only helps if 128 bits is big enough.

I don't think I've ever seen a C compiler that supports 128-bit
integers.  Can you provide an example?

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#27535

On Mon, 22 Oct 2012 10:31:54 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>David Brown <david@westcontrol.removethisbit.com> writes:
>> On 22/10/2012 11:11, boltar2003@boltar.world wrote:
>>> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
>>> very large numbers (stored in char arrays presumably)? ie The sort of numbers
>>> that have no chance of fitting in even a 64 bit int or double. Or failing
>>
>> If your numbers will fit into 128-bit ints, then I think it is quite 
>> common to support 128-bit types in 64-bit compilers, and they will be 
>> much more efficient than arbitrarily long number libraries.  But that 
>> only helps if 128 bits is big enough.
>
>I don't think I've ever seen a C compiler that supports 128-bit
>integers.  Can you provide an example?


Doesn't Jacob Navia's?  And GCC on 64 bit targets usually has at least
partial support.

[toc] | [prev] | [next] | [standalone]

#27545

Robert Wessel <robertwessel2@yahoo.com> writes:

> On Mon, 22 Oct 2012 10:31:54 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>
>>David Brown <david@westcontrol.removethisbit.com> writes:
>>> On 22/10/2012 11:11, boltar2003@boltar.world wrote:
>>>> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
>>>> very large numbers (stored in char arrays presumably)? ie The sort of numbers
>>>> that have no chance of fitting in even a 64 bit int or double. Or failing
>>>
>>> If your numbers will fit into 128-bit ints, then I think it is quite 
>>> common to support 128-bit types in 64-bit compilers, and they will be 
>>> much more efficient than arbitrarily long number libraries.  But that 
>>> only helps if 128 bits is big enough.
>>
>>I don't think I've ever seen a C compiler that supports 128-bit
>>integers.  Can you provide an example?
>
>
> Doesn't Jacob Navia's?  And GCC on 64 bit targets usually has at least
> partial support.

It supports a type called int128, but it's not an integer type.  For
example, you can't cast it to another integer type.  It's implemented as
a struct using lcc-win32's operator overloading so it's a matter of
debate if a program using it is using a "C compiler".  Jacob's operator
overloading is deliberately unobtrusive but I have not studied the
consequences of not using the compiler in a conforming mode.

gcc provides __int128 "for targets having an integer mode wide enough to
hold 128-bit".  I'm not sure exactly what's included in that.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27565

On 23/10/2012 01:01, Ben Bacarisse wrote:
> Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> On Mon, 22 Oct 2012 10:31:54 -0700, Keith Thompson <kst-u@mib.org>
>> wrote:
>>
>>> David Brown <david@westcontrol.removethisbit.com> writes:
>>>> On 22/10/2012 11:11, boltar2003@boltar.world wrote:
>>>>> Does anyone know of an API that will do standard math ops (*,+,-,/,% etc) on
>>>>> very large numbers (stored in char arrays presumably)? ie The sort of numbers
>>>>> that have no chance of fitting in even a 64 bit int or double. Or failing
>>>>
>>>> If your numbers will fit into 128-bit ints, then I think it is quite
>>>> common to support 128-bit types in 64-bit compilers, and they will be
>>>> much more efficient than arbitrarily long number libraries.  But that
>>>> only helps if 128 bits is big enough.
>>>
>>> I don't think I've ever seen a C compiler that supports 128-bit
>>> integers.  Can you provide an example?
>>
>>
>> Doesn't Jacob Navia's?  And GCC on 64 bit targets usually has at least
>> partial support.
>
> It supports a type called int128, but it's not an integer type.  For
> example, you can't cast it to another integer type.  It's implemented as
> a struct using lcc-win32's operator overloading so it's a matter of
> debate if a program using it is using a "C compiler".  Jacob's operator
> overloading is deliberately unobtrusive but I have not studied the
> consequences of not using the compiler in a conforming mode.
>
> gcc provides __int128 "for targets having an integer mode wide enough to
> hold 128-bit".  I'm not sure exactly what's included in that.
>

gcc certainly provides it for 64-bit amd64 targets - and I'm guessing 
also for other 64-bit targets (such as PPC, MIPS, IA-64).  It is treated 
much like any other integer type as far as gcc is concerned.  Generated 
code will use two registers and twice as many operations compared to 
64-bit integers, but that's standard for C compilers working with 
integers wider than the registers.

It would not surprise me unduly if gcc supported 128-bit integers on 
32-bit targets as well (after all, it happily supports 64-bit integers 
on 8-bit targets), but I haven't checked.

[toc] | [prev] | [next] | [standalone]

#27571

On Tue, Oct 23, 2012 at 09:38:00AM +0200, David Brown wrote:
> On 23/10/2012 01:01, Ben Bacarisse wrote:
> >Robert Wessel <robertwessel2@yahoo.com> writes:
> >
> >>On Mon, 22 Oct 2012 10:31:54 -0700, Keith Thompson <kst-u@mib.org>
> >>wrote:
> >>
> >>>David Brown <david@westcontrol.removethisbit.com> writes:
> >>>>On 22/10/2012 11:11, boltar2003@boltar.world wrote:
> >>>>>Does anyone know of an API that will do standard math ops (*,+,-,/,% 
> >>>>>etc) on
> >>>>>very large numbers (stored in char arrays presumably)? ie The sort of 
> >>>>>numbers
> >>>>>that have no chance of fitting in even a 64 bit int or double. Or 
> >>>>>failing
> >>>>
> >>>>If your numbers will fit into 128-bit ints, then I think it is quite
> >>>>common to support 128-bit types in 64-bit compilers, and they will be
> >>>>much more efficient than arbitrarily long number libraries.  But that
> >>>>only helps if 128 bits is big enough.
> >>>
> >>>I don't think I've ever seen a C compiler that supports 128-bit
> >>>integers.  Can you provide an example?
> >>
> >>
> >>Doesn't Jacob Navia's?  And GCC on 64 bit targets usually has at least
> >>partial support.
> >
> >It supports a type called int128, but it's not an integer type.  For
> >example, you can't cast it to another integer type.  It's implemented as
> >a struct using lcc-win32's operator overloading so it's a matter of
> >debate if a program using it is using a "C compiler".  Jacob's operator
> >overloading is deliberately unobtrusive but I have not studied the
> >consequences of not using the compiler in a conforming mode.
> >
> >gcc provides __int128 "for targets having an integer mode wide enough to
> >hold 128-bit".  I'm not sure exactly what's included in that.
> >
> 
> gcc certainly provides it for 64-bit amd64 targets - and I'm guessing 
> also for other 64-bit targets (such as PPC, MIPS, IA-64).  It is treated 
> much like any other integer type as far as gcc is concerned.  Generated 
> code will use two registers and twice as many operations compared to 
> 64-bit integers, but that's standard for C compilers working with 
> integers wider than the registers.
> 
> It would not surprise me unduly if gcc supported 128-bit integers on 
> 32-bit targets as well (after all, it happily supports 64-bit integers 
> on 8-bit targets), but I haven't checked.

I was briefly looking at the compiler info pages but I could not
easily determine whether support included all the trig/exponential/etc
math functions or whether it only supports basic arithmetic
operations.  In the latter case, it doesn't seem like it would be all
that useful.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

[toc] | [prev] | [next] | [standalone]

#27577

On 23/10/2012 14:40, Steve Thompson wrote:
> On Tue, Oct 23, 2012 at 09:38:00AM +0200, David Brown wrote:
>> On 23/10/2012 01:01, Ben Bacarisse wrote:
>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>
>>>> On Mon, 22 Oct 2012 10:31:54 -0700, Keith Thompson <kst-u@mib.org>
>>>> wrote:
>>>>
>>>>> David Brown <david@westcontrol.removethisbit.com> writes:
>>>>>> On 22/10/2012 11:11, boltar2003@boltar.world wrote:
>>>>>>> Does anyone know of an API that will do standard math ops (*,+,-,/,%
>>>>>>> etc) on
>>>>>>> very large numbers (stored in char arrays presumably)? ie The sort of
>>>>>>> numbers
>>>>>>> that have no chance of fitting in even a 64 bit int or double. Or
>>>>>>> failing
>>>>>>
>>>>>> If your numbers will fit into 128-bit ints, then I think it is quite
>>>>>> common to support 128-bit types in 64-bit compilers, and they will be
>>>>>> much more efficient than arbitrarily long number libraries.  But that
>>>>>> only helps if 128 bits is big enough.
>>>>>
>>>>> I don't think I've ever seen a C compiler that supports 128-bit
>>>>> integers.  Can you provide an example?
>>>>
>>>>
>>>> Doesn't Jacob Navia's?  And GCC on 64 bit targets usually has at least
>>>> partial support.
>>>
>>> It supports a type called int128, but it's not an integer type.  For
>>> example, you can't cast it to another integer type.  It's implemented as
>>> a struct using lcc-win32's operator overloading so it's a matter of
>>> debate if a program using it is using a "C compiler".  Jacob's operator
>>> overloading is deliberately unobtrusive but I have not studied the
>>> consequences of not using the compiler in a conforming mode.
>>>
>>> gcc provides __int128 "for targets having an integer mode wide enough to
>>> hold 128-bit".  I'm not sure exactly what's included in that.
>>>
>>
>> gcc certainly provides it for 64-bit amd64 targets - and I'm guessing
>> also for other 64-bit targets (such as PPC, MIPS, IA-64).  It is treated
>> much like any other integer type as far as gcc is concerned.  Generated
>> code will use two registers and twice as many operations compared to
>> 64-bit integers, but that's standard for C compilers working with
>> integers wider than the registers.
>>
>> It would not surprise me unduly if gcc supported 128-bit integers on
>> 32-bit targets as well (after all, it happily supports 64-bit integers
>> on 8-bit targets), but I haven't checked.
>
> I was briefly looking at the compiler info pages but I could not
> easily determine whether support included all the trig/exponential/etc
> math functions or whether it only supports basic arithmetic
> operations.  In the latter case, it doesn't seem like it would be all
> that useful.
>

Why would you be looking for trig/exponential/etc support for 128-bit 
integers?  Are you mixing them up with __float128, which is also 
supported by gcc on some targets (including x86_64)?

I haven't tried any of this myself, but gcc supports a large number of 
functions on "long long int" and "long double" numbers.  These are not 
necessarily 128 bits, however.  I /think/ "long double" will be 128-bit, 
on targets that support it.  But "long long int" is more likely to be 
64-bit (it really has to be 64-bit on targets such as Win64 that have 
32-bit longs).  That is certainly the results of my brief testing on 
64-bit Linux.

[toc] | [prev] | [next] | [standalone]

#27595

On Tue, Oct 23, 2012 at 04:23:33PM +0200, David Brown wrote:
> On 23/10/2012 14:40, Steve Thompson wrote:
> >On Tue, Oct 23, 2012 at 09:38:00AM +0200, David Brown wrote:
> >>On 23/10/2012 01:01, Ben Bacarisse wrote:
> >>>Robert Wessel <robertwessel2@yahoo.com> writes:
> >>>
> >>>>On Mon, 22 Oct 2012 10:31:54 -0700, Keith Thompson <kst-u@mib.org>
> >>>>wrote:
> >>>>
> >>>>>David Brown <david@westcontrol.removethisbit.com> writes:
> >>>>>>On 22/10/2012 11:11, boltar2003@boltar.world wrote:
> >>>>>>>Does anyone know of an API that will do standard math ops (*,+,-,/,%
> >>>>>>>etc) on
> >>>>>>>very large numbers (stored in char arrays presumably)? ie The sort of
> >>>>>>>numbers
> >>>>>>>that have no chance of fitting in even a 64 bit int or double. Or
> >>>>>>>failing
> >>>>>>
> >>>>>>If your numbers will fit into 128-bit ints, then I think it is quite
> >>>>>>common to support 128-bit types in 64-bit compilers, and they will be
> >>>>>>much more efficient than arbitrarily long number libraries.  But that
> >>>>>>only helps if 128 bits is big enough.
> >>>>>
> >>>>>I don't think I've ever seen a C compiler that supports 128-bit
> >>>>>integers.  Can you provide an example?
> >>>>
> >>>>
> >>>>Doesn't Jacob Navia's?  And GCC on 64 bit targets usually has at least
> >>>>partial support.
> >>>
> >>>It supports a type called int128, but it's not an integer type.  For
> >>>example, you can't cast it to another integer type.  It's implemented as
> >>>a struct using lcc-win32's operator overloading so it's a matter of
> >>>debate if a program using it is using a "C compiler".  Jacob's operator
> >>>overloading is deliberately unobtrusive but I have not studied the
> >>>consequences of not using the compiler in a conforming mode.
> >>>
> >>>gcc provides __int128 "for targets having an integer mode wide enough to
> >>>hold 128-bit".  I'm not sure exactly what's included in that.
> >>>
> >>
> >>gcc certainly provides it for 64-bit amd64 targets - and I'm guessing
> >>also for other 64-bit targets (such as PPC, MIPS, IA-64).  It is treated
> >>much like any other integer type as far as gcc is concerned.  Generated
> >>code will use two registers and twice as many operations compared to
> >>64-bit integers, but that's standard for C compilers working with
> >>integers wider than the registers.
> >>
> >>It would not surprise me unduly if gcc supported 128-bit integers on
> >>32-bit targets as well (after all, it happily supports 64-bit integers
> >>on 8-bit targets), but I haven't checked.
> >
> >I was briefly looking at the compiler info pages but I could not
> >easily determine whether support included all the trig/exponential/etc
> >math functions or whether it only supports basic arithmetic
> >operations.  In the latter case, it doesn't seem like it would be all
> >that useful.
> >
> 
> Why would you be looking for trig/exponential/etc support for 128-bit 
> integers?  Are you mixing them up with __float128, which is also 
> supported by gcc on some targets (including x86_64)?
> 
> I haven't tried any of this myself, but gcc supports a large number of 
> functions on "long long int" and "long double" numbers.  These are not 
> necessarily 128 bits, however.  I /think/ "long double" will be 128-bit, 
> on targets that support it.  But "long long int" is more likely to be 
> 64-bit (it really has to be 64-bit on targets such as Win64 that have 
> 32-bit longs).  That is certainly the results of my brief testing on 
> 64-bit Linux.

Oops, brain fart.  You're right.  Recently I was reading about the
various float lengths, the 32, 64, 80, and 128 bit types and conflated
the two while I was sleep-deprived last night.  That carried through
to this morning when I started posting before the coffee started
working.



Regards,

Steve Thompson

-- 
GOTO's are like guns.  Safety is entirely contingent on the user.

[toc] | [prev] | [next] | [standalone]

#27601

David Brown <david@westcontrol.removethisbit.com> writes:
> On 23/10/2012 01:01, Ben Bacarisse wrote:
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>> On Mon, 22 Oct 2012 10:31:54 -0700, Keith Thompson <kst-u@mib.org>
>>> wrote:
[...]
>>>> I don't think I've ever seen a C compiler that supports 128-bit
>>>> integers.  Can you provide an example?
>>>
>>> Doesn't Jacob Navia's?  And GCC on 64 bit targets usually has at least
>>> partial support.
>>
>> It supports a type called int128, but it's not an integer type.  For
>> example, you can't cast it to another integer type.  It's implemented as
>> a struct using lcc-win32's operator overloading so it's a matter of
>> debate if a program using it is using a "C compiler".  Jacob's operator
>> overloading is deliberately unobtrusive but I have not studied the
>> consequences of not using the compiler in a conforming mode.
>>
>> gcc provides __int128 "for targets having an integer mode wide enough to
>> hold 128-bit".  I'm not sure exactly what's included in that.
>
> gcc certainly provides it for 64-bit amd64 targets - and I'm guessing
> also for other 64-bit targets (such as PPC, MIPS, IA-64).  It is
> treated much like any other integer type as far as gcc is concerned.
> Generated code will use two registers and twice as many operations
> compared to 64-bit integers, but that's standard for C compilers
> working with integers wider than the registers.
>
> It would not surprise me unduly if gcc supported 128-bit integers on
> 32-bit targets as well (after all, it happily supports 64-bit integers
> on 8-bit targets), but I haven't checked.

gcc 4.7 does *not* support __int128 on 32-bit x86.

On a 64-bit system (I have "x86_64-w64-mingw32-gcc" version 4.5.3
under Cygwin), it does support __int128 -- but intmax_t is still
only 64 bits.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#27619

On 23/10/2012 21:58, Keith Thompson wrote:
> David Brown <david@westcontrol.removethisbit.com> writes:
>> On 23/10/2012 01:01, Ben Bacarisse wrote:
>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>> On Mon, 22 Oct 2012 10:31:54 -0700, Keith Thompson <kst-u@mib.org>
>>>> wrote:
> [...]
>>>>> I don't think I've ever seen a C compiler that supports 128-bit
>>>>> integers.  Can you provide an example?
>>>>
>>>> Doesn't Jacob Navia's?  And GCC on 64 bit targets usually has at least
>>>> partial support.
>>>
>>> It supports a type called int128, but it's not an integer type.  For
>>> example, you can't cast it to another integer type.  It's implemented as
>>> a struct using lcc-win32's operator overloading so it's a matter of
>>> debate if a program using it is using a "C compiler".  Jacob's operator
>>> overloading is deliberately unobtrusive but I have not studied the
>>> consequences of not using the compiler in a conforming mode.
>>>
>>> gcc provides __int128 "for targets having an integer mode wide enough to
>>> hold 128-bit".  I'm not sure exactly what's included in that.
>>
>> gcc certainly provides it for 64-bit amd64 targets - and I'm guessing
>> also for other 64-bit targets (such as PPC, MIPS, IA-64).  It is
>> treated much like any other integer type as far as gcc is concerned.
>> Generated code will use two registers and twice as many operations
>> compared to 64-bit integers, but that's standard for C compilers
>> working with integers wider than the registers.
>>
>> It would not surprise me unduly if gcc supported 128-bit integers on
>> 32-bit targets as well (after all, it happily supports 64-bit integers
>> on 8-bit targets), but I haven't checked.
>
> gcc 4.7 does *not* support __int128 on 32-bit x86.

Fair enough.  128-bit support on x86-32 would be really messy, due to 
the lack of registers, so I can well see why no one has made support for 
it.  It would be easier on an architecture with lots of registers, such 
as PPC-32 or MIPS-32, but it would still depend on someone actually 
wanting to /use/ 128-bit on 32-bit targets.

>
> On a 64-bit system (I have "x86_64-w64-mingw32-gcc" version 4.5.3
> under Cygwin), it does support __int128 -- but intmax_t is still
> only 64 bits.
>

I noticed that (on gcc 4.5 on Linux-64).  There is also no int128_t or 
related types in <stdint.h>.  And there is no way to express an int128_t 
literal for targets that whose "long long" is smaller than 128 bits.  On 
x86-64, "long long" is 64-bit (with "long" being 32-bit on Windows, 
64-bit on Linux), so until "long long long int" or "really long int" is 
added to C, the language is missing a bit of support for 128-bit integers.

Still, you can use them happily for arithmetic if it suits your needs.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web