Hello,

In my continued, though stalled, effort to try and make minimal runtime for embedded systems, I've tried to find a way for users to know at compile-time if a feature of the runtime is supported or not, and more importantly, if they are explicitly or implicitly using an unsupported feature.

I'm not really in favor of adding a lot of compiler switches that create a new dialect of the language, though I'd take it if it were the only way.  I'd rather have druntime inform the compiler what is or isn't supported, and avoid compiler changes.

I've recently realized that druntime doesn't really have to be any different than other libraries: if a function isn't supported it simply isn't declared in the library's headers. If users make use of the undeclared function, explicitly or implicity, they get a compiler error, just like they would with any other library.  Currently these library hooks are all declared in d-codegen.cc (https://github.com/D-Programming-GDC/GDC/blob/9a05197e64031b96fda72a4428e9bb9b7e37ff01/gcc/d/d-codegen.cc) and documented at http://wiki.dlang.org/Runtime_Hooks

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.

Of course there would have to be changes to the compiler to implement this idea, but I think it would be completely transparent to users.

Advantages:
* It will make it easier to implement a more polished minimal druntime, a "D as a better C", or some other variation of the language without having to resort to compiler changes.  Such a runtime has been asked for several times on these forums and even proposed by Walter.  This change won't eliminate calls for certain compiler switches, but it will provide developers with a few more tools to hopefully avoid them.

* It makes the language more consistent.  Runtime hooks could become less "special" to the language and the compiler, and can be treated just like any other library function: If the declaration doesn't exist, compiler error.

* Runtime hooks can be easily decorated with @deprecated or other attributes and enable several techniques to test language changes without having to rebuild the compiler.

Thanks for your thoughtful consideration,

Mike

On 11 October 2014 07:59, Mike via D.gnu <d.gnu@puremagic.com> wrote:
> Hello,
>
> In my continued, though stalled, effort to try and make minimal runtime for embedded systems, I've tried to find a way for users to know at compile-time if a feature of the runtime is supported or not, and more importantly, if they are explicitly or implicitly using an unsupported feature.
>
> I'm not really in favor of adding a lot of compiler switches that create a new dialect of the language, though I'd take it if it were the only way. I'd rather have druntime inform the compiler what is or isn't supported, and avoid compiler changes.
>
> I've recently realized that druntime doesn't really have to be any different
> than other libraries: if a function isn't supported it simply isn't declared
> in the library's headers. If users make use of the undeclared function,
> explicitly or implicity, they get a compiler error, just like they would
> with any other library.  Currently these library hooks are all declared in
> d-codegen.cc
> (https://github.com/D-Programming-GDC/GDC/blob/9a05197e64031b96fda72a4428e9bb9b7e37ff01/gcc/d/d-codegen.cc)
> and documented at http://wiki.dlang.org/Runtime_Hooks
>
> 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.
>
> Of course there would have to be changes to the compiler to implement this idea, but I think it would be completely transparent to users.
>
> Advantages:
> * It will make it easier to implement a more polished minimal druntime, a "D
> as a better C", or some other variation of the language without having to
> resort to compiler changes.  Such a runtime has been asked for several times
> on these forums and even proposed by Walter.  This change won't eliminate
> calls for certain compiler switches, but it will provide developers with a
> few more tools to hopefully avoid them.
>
> * It makes the language more consistent.  Runtime hooks could become less "special" to the language and the compiler, and can be treated just like any other library function: If the declaration doesn't exist, compiler error.
>
> * Runtime hooks can be easily decorated with @deprecated or other attributes and enable several techniques to test language changes without having to rebuild the compiler.
>
> Thanks for your thoughtful consideration,
>
> Mike

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.

On Saturday, 11 October 2014 at 06:59:33 UTC, Mike wrote:
> Hello,
>
> In my continued, though stalled, effort to try and make minimal runtime for embedded systems, I've tried to find a way for users to know at compile-time if a feature of the runtime is supported or not, and more importantly, if they are explicitly or implicitly using an unsupported feature.

I have started work myself on a D kernel (using gdc based on 2.065 as compiler) and am going through the process of figuring out how the D runtime works.  I have looked at XOMB and Adam Ruppe's minimal-d, and saw the presentation online on running D on ARM.

I can boot and call D functions, but most of the D language remains unavailable.  I am locating the various dependencies of object.d(i) now, and hope to be able to soon be able to at least complete a link with D code that has structs and enums.  I am currently using 2.065 druntime, adding only those bits of object.d that the compiler is directly referencing, and versioning my changes with version(BareBones).

Is your work online somewhere?  Would it be OK if I took a peek?  Mine just started (seriously, it is just hello world) over at:  https://github.com/klamonte/cycle

I would really like a micro-runtime that supports the D dialect minus GC, Threads, synchronization, OS APIs, and i386/amd64 arch-specific things like atomic operations.  So far (crossing fingers) it seems like such a thing is only about 5-10 kloc.

Am Sat, 11 Oct 2014 17:37:20 +0000
schrieb "Kevin Lamonte" <kevindotlamnodotonte@gmail.com>:

> On Saturday, 11 October 2014 at 06:59:33 UTC, Mike wrote:
> > Hello,
> >
> > In my continued, though stalled, effort to try and make minimal runtime for embedded systems, I've tried to find a way for users to know at compile-time if a feature of the runtime is supported or not, and more importantly, if they are explicitly or implicitly using an unsupported feature.
> 
> I have started work myself on a D kernel (using gdc based on 2.065 as compiler) and am going through the process of figuring out how the D runtime works.  I have looked at XOMB and Adam Ruppe's minimal-d, and saw the presentation online on running D on ARM.
> 
> I can boot and call D functions, but most of the D language remains unavailable.  I am locating the various dependencies of object.d(i) now, and hope to be able to soon be able to at least complete a link with D code that has structs and enums.  I am currently using 2.065 druntime, adding only those bits of object.d that the compiler is directly referencing, and versioning my changes with version(BareBones).
> 
> Is your work online somewhere?  Would it be OK if I took a peek? Mine just started (seriously, it is just hello world) over at: https://github.com/klamonte/cycle
> 
> I would really like a micro-runtime that supports the D dialect minus GC, Threads, synchronization, OS APIs, and i386/amd64 arch-specific things like atomic operations.  So far (crossing fingers) it seems like such a thing is only about 5-10 kloc.

You could also have a look at https://github.com/jpf91/GDC/tree/microD

Right now it's just an experiment and I don't know if anything will be upstreamed.

On Saturday, 11 October 2014 at 17:37:22 UTC, Kevin Lamonte wrote:
> On Saturday, 11 October 2014 at 06:59:33 UTC, Mike wrote:
>> Hello,
>>
>> In my continued, though stalled, effort to try and make minimal runtime for embedded systems, I've tried to find a way for users to know at compile-time if a feature of the runtime is supported or not, and more importantly, if they are explicitly or implicitly using an unsupported feature.
>
> I have started work myself on a D kernel (using gdc based on 2.065 as compiler) and am going through the process of figuring out how the D runtime works.  I have looked at XOMB and Adam Ruppe's minimal-d, and saw the presentation online on running D on ARM.
>
> I can boot and call D functions, but most of the D language remains unavailable.  I am locating the various dependencies of object.d(i) now, and hope to be able to soon be able to at least complete a link with D code that has structs and enums.  I am currently using 2.065 druntime, adding only those bits of object.d that the compiler is directly referencing, and versioning my changes with version(BareBones).
>
> Is your work online somewhere?  Would it be OK if I took a peek?  Mine just started (seriously, it is just hello world) over at:  https://github.com/klamonte/cycle
>
> I would really like a micro-runtime that supports the D dialect minus GC, Threads, synchronization, OS APIs, and i386/amd64 arch-specific things like atomic operations.  So far (crossing fingers) it seems like such a thing is only about 5-10 kloc.

Sounds like you you and I are after pretty much the same thing.  I'm not really trying to build anything, like a kernel, just yet.  Rather, I'm just trying to get a decent runtime built so we can all have a reasonably polished language to work with.

You can find my work here: https://github.com/JinShil/druntime_level_0.  I'm afraid it's not any further along then yours.  I actually became quite discouraged and stalled.  I'm trying to explore other options, hence this post.

Mike

On Sunday, 12 October 2014 at 00:12:47 UTC, Mike wrote:
> Sounds like you you and I are after pretty much the same thing.
>  I'm not really trying to build anything, like a kernel, just yet.
>  Rather, I'm just trying to get a decent runtime built so we can all have a reasonably polished language to work with.
>
> You can find my work here: https://github.com/JinShil/druntime_level_0.  I'm afraid it's not any further along then yours.  I actually became quite discouraged and stalled.  I'm trying to explore other options, hence this post.

Thank you for the pointer, I'll be checking in periodically.

I'm linking now with a restricted subset of druntime, and capable of minimally using structs and enums.  (That's actually almost enough to write a C-language kernel using GDC. :-) )

I am thinking of two useful outcomes from this GDC feature request:

1. A "libd.di" listing all of the extern function signatures the compiler can automatically insert.  (They can remain in mangled form for now, ddemangle does good enough.)  This would clear the way for many new runtimes to be built.

2. Initiate discussion between GDC/LDC2/DMD on one or more version labels for druntime features (what you have as level0, level1, etc.).  This would not only help enable new runtimes feed implementations back to upstream druntime, it would also help identify where druntime can be refactored for internal decoupling.  This would permit things like pluggable GCs.

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

On 13 January 2015 at 10:17, Mike via D.gnu <d.gnu@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.

On Tuesday, 13 January 2015 at 10:49:43 UTC, Iain Buclaw via
D.gnu wrote:
>
> 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.

Thanks, Iain.  I patiently await any assistance you can provide.