On Sunday, 14 January 2018 at 23:03:27 UTC, Andrei Alexandrescu
wrote:
Thanks for these thoughts!
* (u)cent support
* fixes for the shared qualifier
* ownership mechanism
These took less than 1h to add support for? That would be
awesome... but realistically only the (u)cent sounds like that
size of effort.
Agreed. That would be already a plus, as it would allow to do all
the crypto in D.
I've always wondered why we can't implement struct
LargeInt(uint bytes) as a library mechanism for larged
fixed-size integers, with asm specialization for LargeInt!8. Is
adding the type to the compiler necessary, and if so, why?
Asm specialization would not be ideal. Compilers have a pass
called legalization where they break down the operation of types
larger than the largest the plateform support into a series of
operations on smaller types. It can generate specific pattern
that the rest of the compiler is able to understand and optimize
for.
This result in the use of instruction that would be very
difficult for the compiler to reconstruct from the use of smaller
integer types, such as mulhi.
Using asm is not ideal, unless the whole routine is written in
asm, because the compiler find itself to optimize it, for
instance after inlining. So even if it can inline - modern
compiler can inline asm under specific circumstances, it finds
itself unable to optimize operations at a higher level such as
doing (a + b) + (c + d) instead of ((a + b) + c) + d.
Having larger types than 128 bits is not really necessary as you
can leverage 128bits integers and do the magic yourself. For
instance, to add two 256 bits integers represented as ulong[4],
you can do:
ucent acc = 0;
ulong result[4];
for (i; 0 .. 4) {
acc += a[i];
acc += b[i];
result[i] = cast(ulong) acc;
acc >>= 64;
}
This will generate the ideal code on a modern optimizing
compiler. Doing the same thing using only ulong will not generate
good code as the compiler would have to understand from the
techniques you used that you are indeed making addition porting
the carry over. The problem gets even more hairy for
multiplications.
