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

[Dmitry Olshansky via Digitalmars-d]

09-Jan-2015 05:07, Mike пишет:
> 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.
>

These are good. I expect more customization points to come as bare-metal 
stuff moves along.

"high-impact" - I'm not sure I follow? Nobody would notice much except 
those messing with the compiler and custom run-times. The change itself 
might be a couple dozen of lines worth.

I could understand horror that tweaking something in a compiler may 
instill but D's compiler is rapidly evolving. I see nothing fundamental 
in how it depends on run-time and vise-versa, everything is tweakable 
and we break binary compatibility (and not only that) with every release.

> 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

This issue mostly affects embedded targets that run full-fledged OS.

Somehow I see it as a minor issue. No matter how we pile up 
platform-specific headers - somebody got to put it somewhere. A couple 
of conventions were discussed with various drawbacks. Many C projects do 
this in ad-hoc fashion and survive just fine. There is no inherent 
design problem or something "unfixable" - we just need more ports.

Also I'm thinking that bare-metal stuff would simply have its own 
run-time complying with some _spec_ of what compiler expects. Working 
out that spec and importantly language feature sets would be awesome.

>
> 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.

We can just ask for them again and see. It's important to voice concerns 
because there is so much of stuff going on that some important issues 
may easily slip under radar.

What usually works best in prioritizing stuff is highlighting that some 
actual project is having a problem with issue X, Y and Z.

> Due to the fact that they only benefit a
> few bare-metal folks, but impact the full language

Again I'm not sure how? In fact nobody would notice a damn thing. Layout 
of internals of D run-time are just that.


>>
>> 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.
>

Great. This helps me understand what is the main impediment at the 
moment. With that in mind I think we can formulate our GSOC plan better.

As far as I can tell it can focus on 2 paths:

a) Get embedded-savy student to work on MCU support and stuff while 
delegating most compiler tweaks to mentor(s) and core team.

b) Get a student interested in compilers to deliver on getting robust 
cross-compiler with minimal run-time. Getting actual boards to work is 
then delegated to mentors.

I am in favor of a).

>> - 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

Agreed.

-- 
Dmitry Olshansky