• Mike (47/47) Oct 10 2014 Hello,
• Iain Buclaw via D.gnu (24/66) Oct 11 2014 Seems reasonable, and though such a thing may be advantageous on some
• Mike (11/58) Jan 13 2015 I feel silly for what I'm about to ask, but I'm getting
• Iain Buclaw via D.gnu (4/52) Jan 13 2015 I can assist, though timing is a problem as of late. I'll have a list
• Mike (3/8) Jan 13 2015 Thanks, Iain. I patiently await any assistance you can provide.
• Kevin Lamonte (20/26) Oct 11 2014 I have started work myself on a D kernel (using gdc based on
• Johannes Pfau (6/37) Oct 11 2014 You could also have a look at
• Mike (11/38) Oct 11 2014 Sounds like you you and I are after pretty much the same thing.
• Kevin Lamonte (17/27) Oct 12 2014 Thank you for the pointer, I'll be checking in periodically.

"Mike" <none none.com> writes:

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

"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:

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.

"Mike" <none none.com> writes:

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

"Iain Buclaw via D.gnu" <d.gnu puremagic.com> writes:

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.

"Mike" <none none.com> writes:

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.

"Kevin Lamonte" <kevindotlamnodotonte gmail.com> writes:

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.

Johannes Pfau <nospam example.com> writes:

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.

"Mike" <none none.com> writes:

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

"Kevin Lamonte" <kevindotlamnodotonte gmail.com> writes:

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.