H1 2015 Priorities and Bare-Metal Programming

Sun Feb 1 05:05:19 PST 2015

On Sunday, 1 February 2015 at 06:37:27 UTC, Walter Bright wrote:
>
> I don't recall what you've suggested in this vein that was very 
> unpopular - can you please post an example?

These are not in any particular order.  They are just how I 
remember them.

I don't care if everyone disagrees with them, but Rust has shown 
the benefits of a minimal, nimble runtime with modular language 
implementation [7], and I don't see why D can't compete and offer 
something even better.

Issue 11666 - Separate each platform's port to its own 
folder/file [1]
----------------------------------------------------------------------
Originally Ian Buclaw's idea, but the Bugzilla issue was filed by 
me.  The problem is it is difficult to see the abstractions in 
the runtime, because one has to navigate through hierarchies of 
`version`ing, making it difficult to port D to new platforms.  
The solution is to organize it by platform/architecture 
separating each into its own folder.  While there were a few pull 
requests attempting to address this, they all failed, mostly due 
to the fact that participants could not agree how to organize the 
Linux/Posix platform headers.

That made me wonder: What in the world are the the platform 
bindings doing in druntime anyway, and why should they interfere 
11666?  druntime is supposed to be the language implementation.  
If platform bindings are needed, fine, get them from Deimos, and 
encapsulate them.  If users need platform bindings, they can get 
the from Deimos too, and the linker can sort things out.

I brought this up when the community was considering adding C++ 
standard library language bindings to druntime as well (yikes!).  
I tried to intervene, and took a beating [2].  I was criticised 
for whining instead of contributing with pull requests.  Well, I 
did submit a pull request for the most unintrusive, 
uncontroversial, trivial thing I could think of to get the ball 
rolling [3].  But I was told I should discuss it on the forum.  I 
decided to stop the ridiculous cycle of discussion and debate, 
and did not go back to the forum, as it was clear where that 
would have ended up.

If druntime was simply the language implementation, 11666 would 
have been resolved without debate, and we'd have a 
well-structured code base for the community to gradually and 
incrementally bring D to more platforms and architectures, 
without having to go their own way with their own runtime and 
their own tools.

I think the stuff in core.sys.* needs to be deported to Deimos, 
and privately imported by any ports that may need it.  The 
current architecture of druntime is not very portable or 
scalable, especially to the bare-metal architectures.

Issue 13605 - Add ability to `version` a module declaration [4]
---------------------------------------------------------------
One of the issues brought up in 11666 was that using public 
imports introduces new namespaces.  So, in my own experiments, I 
found that if I only had a way to `version` a module, I could 
potentially achieve better encapsulation of a given port.  So, I 
filed this enhancement request. Although this enhancement changes 
nothing for anyone, and simply removes an arbitrary limitation, 
it was still controversial.

Issue 12270 - Move TypeInfo to the D Runtime [5]
------------------------------------------------
If you remember from my and Adam Ruppe's DConf talk, we both 
mentioned the need to stub out TypeInfo in our runtime.  It's a 
silly, but effective hack.  Adam proposed an idea to move 
TypeInfo to the runtime, and I decided to log it in Bugzilla 
because I thought it was a great idea.  But more importantly it's 
a great example for future precedent.

There seems to be something inherently wrong with the way the 
compiler is coupled to the runtime.  I can't put my finger on it, 
but perhaps you know what I'm talking about.  It seems the 
compiler needs to decouple from and delegate more to the runtime. 
  Issue 12270 is a great start in that direction, but 
unfortunately I seem to be the only one of two actually 
interested in it, and I'm disappointed to say I don't know how to 
implement it.  Furthermore, I suspect this may actually break a 
few things if it were implemented, and given the aversion to 
change in this community, my current belief is it would not be 
accepted even if it were implemented.

Moving runtime hook declarations to .di files in the runtime [6]
----------------------------------------------------------------
I want my runtime to inform the compiler which language features 
it supports have the compiler generate errors, at compile-time, 
if the user attempts to use a language feature that is not 
implemented.

Frustrated with the push-back from the larger community, I 
decided to take a lower profile and see if I could have more 
impact from the bottom up. I found GDC's code base a little 
easier to understand than DMD's, and the few bare-metal folks 
there are in this community all seem to hang out at D.GNU anyway. 
  So, I made a few propositions there, one of them being to move 
runtime hook declarations to the runtime (see the link).  None of 
them seemed to light anyone's fire, however, and I have found 
that I still don't understand the compiler well enough to do any 
of the implementations.  Iain has offered to help when he gets 
time, but he's certainly under no obligation to do so, and with 
the community largely silent on the idea, I'm unsure if it will 
be embraced by the community if it were implemented.

Bottom line is some features in D are too high-level and I need a 
way to inform users (at compile time) what language features are 
supported in the runtime port, and which features aren't.  Also, 
I think users should be able to make similar choices even if an 
implementation in the runtime exists.

Final Thoughts
--------------
The D language needs to be more nimble, pay-as-you-go, scalable, 
and portable.  For bare-metal programming, it appears the 
language designers have not really given much thought to it.  As 
I study Rust, I see that someone there is thinking about it and 
making design choices to support it rather elegantly. [7]

*  The D language itself should not be dependent on libc or any 
other library.  Ports of the D runtime may need those libraries, 
but the language itself should not.  libc bindings below in 
Deimos.
*  Those porting D to new platforms shouldn't have to port the 
entire feature set of D, especially for resource-constrained 
bare-metal ports.  They should be able to implement only what is 
applicable for their platform (of course I recognize there is a 
limit).  That is going to look very different for each platform, 
so D should be more modular and malleable.
*  Users should be able to make decisions about what features of 
D they want or don't want in their programs, even if a runtime 
implementation exists, and have those decisions enforced at 
compile-time.
*  Users and those porting D to new platforms should have some 
control over the code generation to make efficient binaries, 
especially for resource constrained systems.  But I also think 
the linker needs to take some responsibility here too.
*  I have more, but I'm already getting carried away.

I don't want to file more Bugzilla issues because I don't 
necessarily have the right answers here, and I think Bugzilla 
issues need to be specific and actionable.  Also, I want to help 
make them happen, and not just throw them in Bugzilla to rot.  
Instead, I'd like some dialogue with those willing to work with 
me to find a reasonable solution and help with the 
implementation.  But I also need to know what the core team will 
welcome, and what they will not, before I decide to jump in with 
both feet.  The aversion to change has me very sceptical.

Mike

[1] - Separate each platform's port to its own folder/file - 
https://issues.dlang.org/show_bug.cgi?id=11666
[2] - core.spp - 
http://forum.dlang.org/post/sdrjfagsayomsngmeywp@forum.dlang.org
[3] - Move core.stdc to Deimos - 
https://github.com/D-Programming-Deimos/libc/pull/2
[4] - Add ability to `version` a module declaration - 
https://issues.dlang.org/show_bug.cgi?id=13605
[5] - Move TypeInfo to D Runtime - 
https://issues.dlang.org/show_bug.cgi?id=12270
[6] - Move runtime hook declarations to .di file in runtime - 
http://forum.dlang.org/post/psssnzurlzeqeneagora@forum.dlang.org
[7] - Writing Safe Unsafe and Low-Level Code in Rust - 
http://doc.rust-lang.org/0.11.0/guide-unsafe.html