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.

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.

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.

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.

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.

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

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