[M3devel] __int128 coming to gcc

Thu Jan 21 04:57:45 CET 2010

But you need certain things to not change *per platform* if you expect to be able to link code together and not crash.
Different platforms of course can use different sizes and such.

It should not be possible to compile one module with one size INTEGER and nother with another size, if they can be linked together.

Various systems do allow that sort of thing and it is imho a bad idea.
It leads to "ABI bifurcation".
Like, let's say you want to provide a library for use by "anyone".
You end up having to compile it multiple times with various options, so that no matter what your user uses, there is a variant that matches.
Sometimes this stuff gets checked at link time, sometimes not.

Again this is why the way user threads is an "option" isn't great.
You have to recompile everything if you switch the option.
(I believe there are incrementality bugs here as well; basically many sorts of m3makefile edits are not handled correctly by cm3; for example moving a source file from one package to another..)

Having [0L .. Long.Shift(1L, 129)] work and use a 128bit LONGINT is a fine idea, agreed. "LONGINT" can indicate "possibly less efficient.

However, this is again a dangerous change *on preexisting platforms*, because it leads to LAST(LONGINT) changing.

 - Jay

----------------------------------------
> Subject: Re: [M3devel] __int128 coming to gcc
> From: darko at darko.org
> Date: Thu, 21 Jan 2010 14:34:26 +1100
> CC: hosking at cs.purdue.edu; m3devel at elegosoft.com
> To: jay.krell at cornell.edu
>
> I think you want to get away from concrete representations on particular platforms. All you need to know is that INTEGER is a good, efficient size for the platform, and LONGINT is possibly bigger size but still reasonably efficient. That way the code will compile on any platform and you don't care what size INTEGER or LONGINT is. If this were a Star Wars movie Obiwan would be saying "Use Abstraction, Jay".
>
>
> On 21/01/2010, at 1:54 PM, Jay K wrote:
>
>
>> I think the idea that "basics" don't change
>> meaning doesn't wash because you can't
>> make assumptions about what hardware you're
>> running on and therefore might be condemning
>> the language to inefficiency on certain hardware.
>>
>> Agreed!
>
>
> The "basics" *for a given target*.
> LINUXLIBC6 will "never" change INTEGER to be other than 32 bits.
> AMD64_LINUX will "never" change INTEGER to be other than 64 bits.
> Some other future platform can use 56 bits or 128 bits or whatever.
>
>
> - Jay
>
>
> ________________________________
>> From: hosking at cs.purdue.edu
>> Date: Wed, 20 Jan 2010 19:35:17 -0500
>> To: darko at darko.org
>> CC: m3devel at elegosoft.com; jay.krell at cornell.edu
>> Subject: Re: [M3devel] __int128 coming to gcc
>>
>>
>>
>> On 20 Jan 2010, at 19:29, Darko wrote:
>>
>> My point is that the LONGINT type should be thought of abstractly as something longer than an INTEGER. It would be great if the compiler used the right sized integer for a subrange with a particular number of members (2^16, 2^32, 2^64 or 2^128), but you might just have to say "don't compile LONGINTS bigger than 64 bits" for efficiency.
>>
>> M3 defines all arithmetic as operating on the base type. It does seem reasonable to be able to build for targets with different-sized LONGINT, just as we do for targets with different-sized INTEGER.
>>
>> You're using the syntax for packed types in your example, but I think they'd have to be subranges.
>>
>> Sorry, yes. [Jet-lag]
>>
>> I think the idea that "basics" don't change meaning doesn't wash because you can't make assumptions about what hardware you're running on and therefore might be condemning the language to inefficiency on certain hardware.
>>
>> Agreed!
>>
>>
>>
>>
>> On 20/01/2010, at 10:20 PM, 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/
>> ....
>>
>>
>>
>>
>>
> 		 	   		  