GSOC - Holiday Edition

[Dmitry Olshansky via Digitalmars-d]

03-Jan-2015 08:25, Mike пишет:
> On Friday, 2 January 2015 at 15:28:58 UTC, Craig Dillabaugh wrote:
>
>> Thanks for all the links, and sorry to hear that things haven't gone
>> well.  Do you think it would be worthwhile having a 'Bare Metal D'
>> project for this year, or do you think we would just be wasting the
>> time of some student?
>
> I think, without a few fundamental changes to the language and the
> runtime, bare-metal programming in D will always be playing second
> fiddle to C, and that significantly diminishes its appeal.  As I and
> others have shown, it can be done, but without the aforementioned
> changes, it will always feel hackish and be viewed as little more than
> an interesting experiment. The changes I'm thinking of would be very
> few, but fundamental breaking changes,

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.

> and that doesn't sit well with
> this community.  Anyone pursuing bare-metal programming in D will need
> to create a slightly different dialect of the language if they want it
> to be a tool rather than a toy.

The only difference of this to e.g. AVR-GCC (used in Arduinos and such) 
toolkits is that all hacks (most are upstream but not all) are already 
done, and packaged in a nice shrink-wrapped box.

> ...and perhaps that would be a better GSOC project.  That is, to fork
> the compiler and runtime and try to make it more suitable for systems
> programming, with "systems programming" being defined as creating the
> first layer of hardware abstraction. Unfortunately, such a project would
> probably not be very interesting to those who enjoy bare-metal
> programming, but rather more for those that have interest in compilers.
> I would not market it as bare-metal programming in D, but as creating a
> bare-metal dialect of D.
>

To clarify a bit my original intents on this project.
In short the goal is to make a toolkit to program a popular range of MCU 
(the list may grow with time) in a subset of D (aka Bare-Metal D).

There is no denying the fact that embedded C/C++ is nothing like normal 
desktop/server ones. C library is barbarically truncated, I'm not even 
saying STL and RTTI, and then countless vendor extensions.

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.

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

Speaking of GSOC: a student is not fighting this fight alone, so mentor 
ought to bring issues to the core team. Secondly a project may consider 
completing top priority goals and secondary goals(goodies). Depending on 
student it can be geared more towards language or more towards embedded 
stuff.

Filing an issues and getting community to help with compiler is totally 
expected.

> That's unfortunate, because if D were designed with bare-metal in mind
> from the start, it would scale well to all programming disciplines.  But
> since it was designed more as an efficient applications programming
> language, you have to hammer to fit, weld to fill, paint to cover to get
> it to scale down to bare-metal.
>

Forth would be excellent then ;) Yet somehow it didn't scale up.

> Long story short:  Bare-metal programming in the current state of D
> would be a fun and educational experiment, but would not be something
> you could sell seriously to industry.  If fun and education is all
> you're after then go for it.

> but a bare-metal dialect of D is what's
> really needed for it to be taken seriously.
>

That's more or less the goal. Though I'd rather stay on the subset of D 
line rather then dialect.

-- 
Dmitry Olshansky