Bare-metal programming in D (was GSOC - Holiday Edition)

[Mike via Digitalmars-d]

On Wednesday, 7 January 2015 at 14:10:49 UTC, Dmitry Olshansky 
wrote:

> Truth be told none of listed in this thread feel fundamental to 
> me. It looks more like a set of patches to each specific 
> problem in the compiler or run-time. Yeah, run-time would 
> better be more customizable, but it's just our *current* 
> run-time it's not the language.
>

Perhaps "high-impact" would be a better word than "fundamental".  
I think moving runtime hooks out of the compiler to .di files and 
Adam Ruppe's proposal to move TypeInfo to the runtime are great 
ideas.

Enhancement 11666 [1] is another.  That really highlighted a 
design problem in the runtime for me.  If the runtime had better 
separation of language, platform (OS and architecture) and 
library, the ports would simply have their own folder in the 
runtime rather than their own repository.  The controversy that 
followed the pull requests in an attempt address 11666 clearly 
shows the problems that high coupling to the platform can cause.  
If the platform were encapsulated and decoupled from the language 
implementation, we'd already be well on our way.

[1] - https://issues.dlang.org/show_bug.cgi?id=11666

But I've been watching how such changes are perceived here, and 
I'm skeptical they would be accepted because so much in the 
language is potentially affected by them.  Due to the fact that 
they only benefit a few bare-metal folks, but impact the full 
language, I'm quite confident they would be shunned, and that's 
been very discouraging.

>
> Thus I do not believe that immediate upstreaming of everything 
> bare-metal is even a good thing in principle. In my opinion a 
> Bare-Metal D project can live its life along the upstream D by 
> providing bare-metal versions of each successive version. In 
> fact, we do not have all that many embedded guys in core team.
>
> All generally useful patches should find their way in upstream, 
> of course, but it takes time and should *not* be a prerequisite.
>

Sure the bare-metal stuff can exist along-side the upstream 
repository.  That's actually what I alluded to in my previous 
posts, that bare-metal programming in D will likely need to fork. 
  In fact, due to the lack of support, I don't see it happening 
any other way.

>
> A toolkit will need to provide e.g build/fetch with a bootstrap 
> script:
> - a ready to-go D cross-compiler(s) might be with some patches 
> to disable language features for better experience etc.

That's more-or-less what I've suggested in this thread.  If that 
happened, I could get behind the items you listed below.  But I 
don't know how to proceed with the compiler, that's not my 
interest nor within my current ability.  Johannes has been 
exploring this territory, however, which is encouraging.

> - a stripped run-time instead of Phobos (come on C/C++ folks 
> use something much unlike standard library either)
> - linker scripts for a (growing) set of MCUs
> - I/O library and register definitions for MCUs (preferably a 
> tool to auto-generate such)
> - a modified driver that passes all kinds of right options for 
> a given MCU
>
> That's a minimum for other Bare Metal D projects to even start 
> to take off. Ideally other tools include debugger, high-level 
> libraries for peripherals (HAL), ports or bindings to C FAT, 
> IP, ... libraries and so on.
>

Let me add that I think the -betterC switch, or similar, is too 
blunt an instrument.  I'd like to have the flexibility to fine 
tune the language features (even on individual types) for the 
platform and/or application I'm building.  And while compiler 
switches and attributes may help, I think delegating features 
from the compiler to the runtime is a better investment.

Mike