For the first time today i had needed the ucent type. Fortunately it was only for bit operations so easy to do as a struct, however this is two hours lost for a type that's in a curious state (rename it shrodinger128 maybe ?).

I think that the feature could be implemented as compiler special functions that would be located in druntime (with special case for GDC and LDC since the type exists in their respective backend if i understand correctly).

On Tuesday, 30 October 2018 at 18:07:23 UTC, Basile B. wrote:

> I think that the feature could be implemented as compiler special functions that would be located in druntime...

Umm, no, thank you very much. It's bad enough that array operations have to go through druntime. Arithmetic types have no business being there whatsoever.

On 10/30/18 2:23 PM, Stanislav Blinov wrote:
> On Tuesday, 30 October 2018 at 18:07:23 UTC, Basile B. wrote:
> 
>> I think that the feature could be implemented as compiler special functions that would be located in druntime...
> 
> Umm, no, thank you very much. It's bad enough that array operations have to go through druntime. Arithmetic types have no business being there whatsoever.

Well, wouldn't it be like a backup implementation if the CPU doesn't have 128-bit registers?

This is actually something I would EXPECT to be in druntime, since it's very platform/compiler specific.

array operations are just there because of legacy (at least in the form they are in).

-Steve

On Tuesday, 30 October 2018 at 18:35:59 UTC, Steven Schveighoffer wrote:
> On 10/30/18 2:23 PM, Stanislav Blinov wrote:
>> On Tuesday, 30 October 2018 at 18:07:23 UTC, Basile B. wrote:
>> 
>>> I think that the feature could be implemented as compiler special functions that would be located in druntime...
>> 
>> Umm, no, thank you very much. It's bad enough that array operations have to go through druntime. Arithmetic types have no business being there whatsoever.
>
> Well, wouldn't it be like a backup implementation if the CPU doesn't have 128-bit registers?

So long as it doesn't compile into shared library calls, I guess it could be fine.

> This is actually something I would EXPECT to be in druntime, since it's very platform/compiler specific.

It's very CPU/compiler-specific, not runtime-specific though.

> array operations are just there because of legacy (at least in the form they are in).

Sad story of D's life :(

On Tuesday, 30 October 2018 at 18:35:59 UTC, Steven Schveighoffer wrote:
> On 10/30/18 2:23 PM, Stanislav Blinov wrote:
>> On Tuesday, 30 October 2018 at 18:07:23 UTC, Basile B. wrote:
>> 
>>> I think that the feature could be implemented as compiler special functions that would be located in druntime...
>> 
>> Umm, no, thank you very much. It's bad enough that array operations have to go through druntime. Arithmetic types have no business being there whatsoever.
>
> Well, wouldn't it be like a backup implementation if the CPU doesn't have 128-bit registers?
>
> This is actually something I would EXPECT to be in druntime, since it's very platform/compiler specific.
>
> array operations are just there because of legacy (at least in the form they are in).
>
> -Steve

There no reason to put it into the druntime. Just have the functions themselves be dynamically compiled during runtime.
https://wiki.dlang.org/LDC-specific_language_changes#.40.28ldc.attributes.dynamicCompile.29

On Tuesday, 30 October 2018 at 19:04:00 UTC, 12345swordy wrote:
> There no reason to put it into the druntime. Just have the functions themselves be dynamically compiled during runtime.
> https://wiki.dlang.org/LDC-specific_language_changes#.40.28ldc.attributes.dynamicCompile.29

Oh yes, there are very good reasons for it. Dynamic compilation would be dog slow for tiny programs, and depend on a ~20 MB DLL for code generation, besides obviously being LDC specific.

On Tuesday, 30 October 2018 at 18:23:59 UTC, Stanislav Blinov wrote:
> On Tuesday, 30 October 2018 at 18:07:23 UTC, Basile B. wrote:
>
>> I think that the feature could be implemented as compiler special functions that would be located in druntime...
>
> Umm, no, thank you very much. It's bad enough that array operations have to go through druntime. Arithmetic types have no business being there whatsoever.

Yes but some operations don't have a matching instruction, for example even on x86_64, shifting requires recent BMI2 instructions because standard SSE integer shifting is done by step of 8 bits only, hence you have to implement the stuff in a specific functions giving an AST that's maybe a bit too complex to be generated by the compiler.

On Tuesday, 30 October 2018 at 19:25:18 UTC, kinke wrote:
> On Tuesday, 30 October 2018 at 19:04:00 UTC, 12345swordy wrote:
>> There no reason to put it into the druntime. Just have the functions themselves be dynamically compiled during runtime.
>> https://wiki.dlang.org/LDC-specific_language_changes#.40.28ldc.attributes.dynamicCompile.29
>
> Oh yes, there are very good reasons for it. Dynamic compilation would be dog slow for tiny programs, and depend on a ~20 MB DLL for code generation, besides obviously being LDC specific.

Dog slow? You compile it once! I don't know that hardware specs that TC is targeting at.

On Tuesday, 30 October 2018 at 20:07:59 UTC, 12345swordy wrote:
> Dog slow? You compile it once! I don't know that hardware specs that TC is targeting at.

You don't compile it at all if its precompiled in druntime. If you don't fancy druntime calls, just use LTO.

On Tue, 30 Oct 2018 20:07:59 +0000, 12345swordy wrote:

> On Tuesday, 30 October 2018 at 19:25:18 UTC, kinke wrote:
>> On Tuesday, 30 October 2018 at 19:04:00 UTC, 12345swordy wrote:
>>> There no reason to put it into the druntime. Just have the functions themselves be dynamically compiled during runtime. https://wiki.dlang.org/LDC-specific_language_changes#.
40.28ldc.attributes.dynamicCompile.29
>>
>> Oh yes, there are very good reasons for it. Dynamic compilation would be dog slow for tiny programs, and depend on a ~20 MB DLL for code generation, besides obviously being LDC specific.
> 
> Dog slow? You compile it once! I don't know that hardware specs that TC is targeting at.

You compile once for every time the executable is run. In many cases, that doesn't matter. In some cases, it's a large problem.

Except with only a small number of JIT-compiled functions, it shouldn't be as large an issue most of the time.

This does mean an indirect call that can't be inlined for most 128-bit math operations. Which might be slower on average than a user-defined struct for fixed-length integers with an arbitrary number of bits.