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
