On 6/10/2018 8:43 PM, Mike Franklin wrote:
> That only addresses the @safe attribute, and that code is much too complex for anyone to audit it and certify it as safe.
> 
> Exceptions are also not all handled, so there is no way it can pass as nothrow.
> 
> The runtime call needs to be replaced with a template that can take advantage of D's compile-time type information instead of `TypeInfo`, but doing so will force the implementation through semantic processing, which, in it's current state, will fail to compile.  It needs to be refactored, and creating @safe, nothrow, pure building blocks will help with that, hence the topic of this thread.

Making it a template is not really necessary. The compiler knows if there is the possibility of it throwing based on the type, it doesn't need to infer it.

(I notice it is doing __doPostblit(). This looks wrong, D allows data to be moved. As far as I can tell with a perfunctory examination, that's the only "can throw" bit.)

Doing without TypeInfo is a worthy goal most of the time, but I don't think it is of much value here because it calls the garbage collector anyway which requires TypeInfo.

Some obvious refactoring tasks for it would be to:

1. eliminate the gotos
2. use single assignment for variables
3. minimize the scopes of variables
4. use const
5. document the inputs and outputs
6. add test cases for the red lines

On 6/10/2018 9:44 PM, Patrick Schluter wrote:
> See what Agner Fog has to say about it:

Thanks. Agner Fog gets the last word on this topic!

On 6/10/2018 8:34 PM, Basile B. wrote:
> - default win32 OMF: https://github.com/DigitalMars/dmc/blob/master/src/core/MEMCCPY.C

I think you mean:

https://github.com/DigitalMars/dmc/blob/master/src/CORE32/MEMCPY.ASM

On Monday, 11 June 2018 at 08:00:10 UTC, Walter Bright wrote:

> Making it a template is not really necessary. The compiler knows if there is the possibility of it throwing based on the type, it doesn't need to infer it.

There are other reasons to make it a template, though.  For example, if it were a template, it would not rely on `TypeInfo` and could then be used in -betterC-like situations.  For setting the length of an array, there are issues with memory allocation that hinder that, but I'm thinking beyond just setting the length of an array here; I just used that as an illustrative example.

I think there might also be optimization opportunities using templates, metaprogramming, and type introspection, that are not currently possible with the current design.

So there are other reasons to pursue a template design for all of our runtime hooks, and if our memcpy, memcmp, etc.. are also templated it't turtles all the way down.  We have to be careful about code bloat with tempates, but I think that can be mitigated.

Mike

On Monday, 11 June 2018 at 08:05:14 UTC, Walter Bright wrote:
> On 6/10/2018 8:34 PM, Basile B. wrote:
>> - default win32 OMF: https://github.com/DigitalMars/dmc/blob/master/src/core/MEMCCPY.C
>
> I think you mean:
>
> https://github.com/DigitalMars/dmc/blob/master/src/CORE32/MEMCPY.ASM

Cool! and it's even boost licensed.  I think I'll try to port that next, before I try the SSE and AVX implementations.

Mike

On 6/11/2018 1:12 AM, Mike Franklin wrote:
> On Monday, 11 June 2018 at 08:00:10 UTC, Walter Bright wrote:
> 
>> Making it a template is not really necessary. The compiler knows if there is the possibility of it throwing based on the type, it doesn't need to infer it.
> 
> There are other reasons to make it a template, though.  For example, if it were a template, it would not rely on `TypeInfo` and could then be used in -betterC-like situations.

We have no design for this function that doesn't rely on the GC, and the GC needs TypeInfo. This function is not usable with betterC with or without the TypeInfo argument.


> I think there might also be optimization opportunities using templates, metaprogramming, and type introspection, that are not currently possible with the current design.

Just making it a template doesn't automatically enable any of this.


> So there are other reasons to pursue a template design for all of our runtime hooks, and if our memcpy, memcmp, etc.. are also templated it't turtles all the way down.

memcpy and memcmp are already handled specially by modern compilers, have been for decades; I seriously doubt there's more oil in that well.

On Monday, 11 June 2018 at 10:07:39 UTC, Walter Bright wrote:

> We have no design for this function that doesn't rely on the GC, and the GC needs TypeInfo. This function is not usable with betterC with or without the TypeInfo argument.

I understand that.  I was using `_d_arraysetlengthT` as an example of problems I encountered trying to convert these runtime hooks into templates, specifically illustrating how the compiler does not enforce the guarantees of safety, nothrow, and pure, and, in fact, completely disregards them.

Converting *any* runtime hook, not just `_d_arraysetlengthT`, to a template comes with a whole host of problems because of the aforementioned issue.  As soon as it's implemented as a template it is semantically analyzed in the context of its caller, so @safe, nothrow, pure, etc. all need to accommodated for.  That's good to have the compiler check for that stuff.  It's unfortunate the current implementation does not, and that's the fault in the current implementation.

There are other runtime hooks that are good candidates for templates, even if `_d_arraysetlengthT` isn't one of them.  Again, I just chose `_d_arraysetlengthT` as an example, because it is the one I had experience with.

Mike

On Monday, 11 June 2018 at 10:07:39 UTC, Walter Bright wrote:

>> I think there might also be optimization opportunities using templates, metaprogramming, and type introspection, that are not currently possible with the current design.
>
> Just making it a template doesn't automatically enable any of this.

I think it does, because I can then generate specific code based on the type information at compile-time.

>> So there are other reasons to pursue a template design for all of our runtime hooks, and if our memcpy, memcmp, etc.. are also templated it't turtles all the way down.
>
> memcpy and memcmp are already handled specially by modern compilers, have been for decades; I seriously doubt there's more oil in that well.

Yes, I may fail to achieve any performance benefits, but even if I achieve parity with the current implementation it will still be a win for me because I will no longer have to depend on the C standard library.  And if I have to fork to use D that way, then that's what I'm going to do.

Mike

On Monday, 11 June 2018 at 10:38:30 UTC, Mike Franklin wrote:
> On Monday, 11 June 2018 at 10:07:39 UTC, Walter Bright wrote:
>
>>> I think there might also be optimization opportunities using templates, metaprogramming, and type introspection, that are not currently possible with the current design.
>>
>> Just making it a template doesn't automatically enable any of this.
>
> I think it does, because I can then generate specific code based on the type information at compile-time.

Also, before you do any more nay-saying, you might want to revisit this talk https://www.youtube.com/watch?v=endKC3fDxqs which demonstrates precisely the kind of benefits that can be achieved with these kinds of changes to the compiler/runtime interface.

Mike

On 6/11/18 4:00 AM, Walter Bright wrote:

> (I notice it is doing __doPostblit(). This looks wrong, D allows data to be moved. As far as I can tell with a perfunctory examination, that's the only "can throw" bit.)

No, __doPostblit is necessary -- you are making a copy.

example:

File[] fs = new File[5];

fs[0] = ...; // initialize fs
auto fs2 = fs;
fs.length = 100;

At this point, fs points at a separate block from fs2. If you did not do postblit on this, then when one of those arrays is destroyed, the other will become invalid, as the File reference count would go to 0.

-Steve