www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Can we have ucent ?

reply Basile B. <b4.temp gmx.com> writes:
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).
Oct 30 2018
next sibling parent reply Stanislav Blinov <stanislav.blinov gmail.com> writes:
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.
Oct 30 2018
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
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
Oct 30 2018
next sibling parent Stanislav Blinov <stanislav.blinov gmail.com> writes:
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 :(
Oct 30 2018
prev sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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
Oct 30 2018
parent reply kinke <noone nowhere.com> writes:
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.
Oct 30 2018
parent reply 12345swordy <alexanderheistermann gmail.com> writes:
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.
Oct 30 2018
next sibling parent kinke <noone nowhere.com> writes:
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.
Oct 30 2018
prev sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
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.
Oct 30 2018
parent 12345swordy <alexanderheistermann gmail.com> writes:
On Tuesday, 30 October 2018 at 22:17:26 UTC, Neia Neutuladh wrote:

 You compile once for every time the executable is run.


Not quite. It only compiles when the compileDynamicCode() 
function is called. It quite possible that the program may never 
call the function and never use the dynamic compile functions.
Oct 30 2018
prev sibling parent Basile B. <b4.temp gmx.com> writes:
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.
Oct 30 2018
prev sibling next sibling parent reply Basile B. <b4.temp gmx.com> writes:
On Tuesday, 30 October 2018 at 18:07:23 UTC, Basile B. wrote:

 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).


Maybe the D foundation could finance a developer for this ? 300 € 
sounds fine imo, because it's not so hard, the guy has to do it 
for DMD and communicate with the LDC/GDC devels so that they put 
the specific backend things. And after it's a long term stuff, 
meaning that ucent/cent types are there.
Oct 31 2018
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 31 October 2018 at 22:02:34 UTC, Basile B. wrote:

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

 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).


 Maybe the D foundation could finance a developer for this ? 300 
 € sounds fine imo, because it's not so hard, the guy has to do 
 it for DMD and communicate with the LDC/GDC devels so that they 
 put the specific backend things. And after it's a long term 
 stuff, meaning that ucent/cent types are there.


The hard parts here are Efficient and correct Division, 
Multiplication as well as Converting from and to Floating-Point.
Oct 31 2018
prev sibling parent kinke <noone nowhere.com> writes:
On Wednesday, 31 October 2018 at 22:02:34 UTC, Basile B. wrote:

 the guy has to do it for DMD and communicate with the LDC/GDC 
 devels so that they put the specific backend things.


LDC (and most likely GDC too) wouldn't have to do much, just 
making use of the `i128` type. The arithmetic operations and 
conversions from/to floating-point are most likely lowered to 
runtime calls anyway, e.g., __multi3 for multiplication 
(https://github.com/llvm-mirror/compiler-rt/blob/master/lib/builtins/multi3.c).
DMD could even simply use LLVM's compiler-rt builtins library containing those
implementations too instead of going through the trouble of porting them to D.
Oct 31 2018
prev sibling next sibling parent solidstate1991 <laszloszeremi outlook.com> writes:
On Tuesday, 30 October 2018 at 18:07:23 UTC, Basile B. wrote:

 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).


I was toying with using SSE2 for bitwise operations, however it 
turned out to be a total waste of time. I was thinking on using 
it for pixel-precise collision detection, but was very unstable 
and prone to bugs, so I defaulted to the previous per-pixel 
detection method but kept the bitarrays for collision shapes.

If I ever going to use a multi-pixel approach, I'm going to do it 
on a per-byte basis: It's way easier on a small scale, especially 
if I put a very common restriction of that the sprites/tiles must 
be the multiple of 8. TransformableTileLayer already have the 
restriction of tile sizes must be the power of two for superfast 
division (through the bit-shift method) and modulo (through "& 
(divider-1)" method) operations.

I was also thinking on using 128bit approach on my LZHAM port, 
but the issue there is that it's very clunky to implement, 
restricted to certain processors and compilers (unless I want to 
go with a hard-to-debug assembly code), and the algorithm 
overhead might make it even slower than 32 or 64bit register 
usage.
Nov 02 2018
prev sibling parent reply Johan Engelen <j j.nl> writes:
On Tuesday, 30 October 2018 at 18:07:23 UTC, Basile B. wrote:

 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).


LDC has had a PR open for adding `ucent` since a long time [*]. 
The biggest implementation hurdle seems to be that we (LDC) don't 
have our own frontend.

In my opinion this effort should be split into two parts:
1 - Add `ucent` support to the frontend (semantic analysis, CTFE)
       Simply emit an error in the backend when `ucent` codegen is 
requested,
       saying that "ucent is not yet supported for the current 
target".
       `wideint` library could be used to do 128-bit math at 
compile-time.
2 - Add `ucent` support to DMD, LDC, GDC backends. (easy for LDC 
and GDC)

- Johan


[*] https://github.com/ldc-developers/ldc/pull/1355
Nov 03 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/3/2018 5:58 AM, Johan Engelen wrote:

 LDC has had a PR open for adding `ucent` since a long time [*]. The biggest 
 implementation hurdle seems to be that we (LDC) don't have our own frontend.
 
 In my opinion this effort should be split into two parts:
 1 - Add `ucent` support to the frontend (semantic analysis, CTFE)
        Simply emit an error in the backend when `ucent` codegen is
requested,
        saying that "ucent is not yet supported for the current target".
        `wideint` library could be used to do 128-bit math at compile-time.
 2 - Add `ucent` support to DMD, LDC, GDC backends. (easy for LDC and GDC)


Yes it could be done like the soft float is currently done for 80 bit reals.

https://github.com/dlang/dmd/blob/master/src/dmd/root/longdouble.d
Nov 03 2018
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Sun, 4 Nov 2018 at 01:50, Walter Bright via Digitalmars-d
<digitalmars-d puremagic.com> wrote:

 On 11/3/2018 5:58 AM, Johan Engelen wrote:

 LDC has had a PR open for adding `ucent` since a long time [*]. The biggest
 implementation hurdle seems to be that we (LDC) don't have our own frontend.

 In my opinion this effort should be split into two parts:
 1 - Add `ucent` support to the frontend (semantic analysis, CTFE)
        Simply emit an error in the backend when `ucent` codegen is requested,
        saying that "ucent is not yet supported for the current target".
        `wideint` library could be used to do 128-bit math at compile-time.
 2 - Add `ucent` support to DMD, LDC, GDC backends. (easy for LDC and GDC)


 Yes it could be done like the soft float is currently done for 80 bit reals.

 https://github.com/dlang/dmd/blob/master/src/dmd/root/longdouble.d


On my todo list. ;-)

https://github.com/dlang/dmd/pull/7699

-- 
Iain
Nov 03 2018