Developing blockchain software with D, not C++

deadalnix deadalnix at gmail.com
Thu Jan 18 03:19:57 UTC 2018


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.


More information about the Digitalmars-d mailing list