RFC: Move runtime hook definitions to a .di file in druntime

[Iain Buclaw via D.gnu]

On 13 January 2015 at 10:17, Mike via D.gnu <d.gnu at puremagic.com> wrote:
> On Saturday, 11 October 2014 at 08:15:55 UTC, Iain Buclaw via D.gnu wrote:
>
>>> So, I'm wondering if the compiler maintainers would entertain a change to
>>> the GDC that moved the runtime declarations (i.e. _d_newclass,
>>> _d_{whatever}) to a .di file in druntime.
>>> * Compilation would automatically import this header.
>>> * The compiler would throw an undefined identifier error if it needs to
>>> make
>>> a call to a runtime hook that isn't declared.
>>> * The.di file could be object.di, since it seems to have already become
>>> the
>>> site for anything to be implicitly imported, but it doesn't have to be.
>
>
>
>> Seems reasonable, and though such a thing may be advantageous on some
>> levels,I believe in the fairness of balance there should be a fair
>> counter argument before drawing up a conclusion.
>>
>> Disadvantages:
>>
>> * The runtime hooks in the *.di file must still match the signature
>> the compiler expects it to be.  In one essence this doesn't loosen the
>> separation between compiler and runtime, it instead makes it more
>> fragile if someone get's their forked version of the runtime hooks
>> wrong.
>>
>> * Possibly extra semantic processing during the mid-flight of codegen
>> may be required to verify that the parameters the compiler generates
>> to pass match the function declaration when generating the call
>> expression.  Ideally the backend should not have to do this.
>>
>> * GDC applies certain special attributes to some runtime functions
>> that can't be applied in normal D code.  Currently only the following
>> associations apply:
>>  1. _d_assert and friends are marked as volatile because they will
>> never return normally.
>>  2. _d_allocmemory is marked as malloc, to allow the compile to
>> optimise more aggressively around inlined functions that create a
>> closure (this can save some needless allocation calls).
>>
>>
>> I'm not knocking this idea though.
>>
>> Iain.
>
>
> I feel silly for what I'm about to ask, but I'm getting desperate...
>
> If there truly is merit to this idea, would anyone be willing to mentor me
> through the implementation? I've tried to get a picture in my mind on how
> the differnt pieces would come together, but I'm not getting it by reading
> the source code.  How would you approach this? Can you formulate it into a
> list of tasks to perform?
>
> Mike
>

I can assist, though timing is a problem as of late.  I'll have a list
of jobs to catch-up on my side before my attention becomes undivided.

Iain.