RFC: Pay-as-you-go, Portable D Runtime for Microcontrollers (and maybe more)

[Dan Olson via Digitalmars-d]

The progress here is nice.  I'd like to do similar stuff with LDC but
have a couple other projects to finish up first.

More thoughts on supporting systems without threads:

"Mike" <none at none.com> writes:
> On Tuesday, 5 May 2015 at 17:27:05 UTC, Johannes Pfau wrote:
>> I'm not really sure about this. It's trivial to implement but it
>> generates a semantic difference which harms code portability
>> (e.g. if
>> you have code where you want a global variable, don't mark it as
>> __gshared and then move to an environment with threads).

I think this could happen anyway.  I write some D code on linux, but my
program doesn't create additional threads so I don't realize I should
have used __gshared somewhere.

Sometime later when I use code in program with multi threads, I discover
my problem that I should have used __gshared on a var.

> I'm coming around and feeling inclined to agree with this.  One of the
> things I want to avoid is creatIng an embedded dialect of the D.  I
> hope D for microcontrollers, kernels and such looks very much like the
> idiomatic D in the application programming domain.

I don't think it changes D, does it?  I want to try to convince here
because I think it opens up a lot of D code for no-thread systems that
would otherwise need to be edited and have __gshared added here and
there.

The language just says a non-immutable global declaration [without
shared or __gshared] lives in thread local storage.  In a single thread
environment, a thread local degenerates to a global, doesn't it?

Looking at it another way.  I could design a "TLS" model for a
non-threaded system that has the compiler puts all "thread local" vars
in section named ".tls" instead of ".data".  Because there is only one
thread, there is only one ".tls" section.  But I could then have linker
merge .tls and .data sections.  And instructions to reference tls and
non-tls vars are identical.

I don't think going the other way is safe.  If a system supports threads
but not TLS, then turning D thread local vars into globals is not good
(however I did do that so I could get initial work done on iOS before I
added TLS to backend).
-- 
Dan