[M3devel] __int128 coming to gcc

[Tony Hosking]

Subranges have a memory size that depends on the size of the subrange.  All arithmetic is performed using the precision of the base type however.

These things are all documented in the language spec.

On 20 Jan 2010, at 21:49, Jay K wrote:

> 
> That would be fine too.
> Or are people suggesting I can just use subranges and the compiler will pick between "int64", "int128", and "error or multiple precision" as it sees fit? Ok.
> 
>  - Jay
> 
> 
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:02:33 -0500
>> To: jay.krell at cornell.edu
>> CC: m3devel at elegosoft.com; darko at darko.org
>> Subject: Re: [M3devel] __int128 coming to gcc
>> 
>> 
>> 
>> But INTEGER is the natural integer size. Not the maximum (perhaps less efficient) integer size supported by the compiler.
>> What's wrong with:
>> 
>> BITS 64 FOR LONGINT
>> 
>> ?
>> 
>> 
>> Antony Hosking | Associate Professor | Computer Science | Purdue University
>> 305 N. University Street | West Lafayette | IN 47907 | USA
>> Office +1 765 494 6001 | Mobile +1 765 427 5484
>> 
>> 
>> 
>> 
>> 
>> 
>> On 20 Jan 2010, at 06:20, Jay K wrote:
>> 
>> Ok with changing LONGINT to be __int128, *but*
>> you really should not change it with a compiler flag.
>> For any given platform, "basics" like this should not change meaning.
>> It makes it such that you can't link code safely.
>> 
>> 
>> Basically, "platform" or "target" should map to one "ABI".
>> 
>> 
>> I really kind of like what I proposed earlier.
>> Let the user define things.
>> TYPE INT64 = BITS 64 FOR INTEGER;
>> TYPE INT128 = BITS 128 FOR INTEGER;
>> 
>> TYPE INT256 = BITS 256 FOR INTEGER;
>> (* either an error, or the compiler generates calls to multi-precision library *)
>> 
>> 
>> This is btw why the user thread stuff should be either 1) a runtime alterable decision
>> or 2) separate platforms (I386_LINUX_USERTHREADS or somesuch).
>> So that there aren't multiple ABIs and you can link together any code for
>> a given platform.
>> With an *occasional* alteration/fix, such as when NT386 LONGINT grows to 64bits.
>> That forces recompilation of everything affected.
>> 
>> 
>> - Jay
>> 
>> 
>> ________________________________
>> Subject: Re: [M3devel] __int128 coming to gcc
>> From: darko at darko.org
>> Date: Wed, 20 Jan 2010 14:23:32 +1100
>> CC: jay.krell at cornell.edu; m3devel at elegosoft.com
>> To: hosking at cs.purdue.edu
>> 
>> I'm with Tony on this one. LONGINT should just mean "larger than the natural integer the machine" and its range should be implementation dependent. You could then change it's actual size with a compiler flag or the like.
>> 
>> 
>> On 19/01/2010, at 1:03 AM, Tony Hosking wrote:
>> 
>> On 18 Jan 2010, at 08:05, Jay K wrote:
>> 
>> gcc 4.6 apparently will have __int128.
>> How long until we have LONGLONGINT or INT128?
>> Presumably we should have LONGLONGINT or INT128 to expose it?
>> :)
>> 
>> Why would we not simply expand LONGINT? It doesn't matter even if it is slow. Then 64-bit can be expressed as
>> 
>> BITS 64 FOR [0L..16_7FFFFFFFFFFFFFFFL]
>> 
>> Or, again, I should look at the arithemetic library...
>> 
>> 
>> - Jay
>> 
>> 
>> Date: Mon, 18 Jan 2010 13:01:13 +0000
>> From: gcc-patches-digest-help@
>> To: gcc-patches@
>> Subject: gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> 
>> gcc-patches Digest 18 Jan 2010 13:01:13 -0000 Issue 14091
>> 
>> ...
>> [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> 255919 by: Kai Tietz
>> 
>> ...
>> 
>> --Forwarded Message Attachment--
>> Date: Mon, 18 Jan 2010 14:01:00 +0100
>> Subject: Re: [patch]: New feature __int128 type C/C++ for upcoming 4.6 for review
>> From: ktietz70@
>> To: joseph@
>> CC: gcc-patches@
>> 
>> 
>> 
>> Hello,
>> 
>> this is the recent version of the __int128 type support as gcc
>> extension. Comments in parser for C and C++ are updated and complex
>> type and tests are added.
>> 
>> ChangeLog gcc/
>> ....
>> 
>> 
>> 
>>