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

[Mike via Digitalmars-d]

On Tuesday, 5 May 2015 at 17:38:38 UTC, Johannes Pfau wrote:

>
> I would probably split the runtime into at least two, probably 
> three
> parts:
>
> * Compiler support library (object.d, gcc/*.d, exception
>   implementation) (module rt/ no module name)
> * Higher level library (portable, micro)
> * Hardware specific library (not portable, avr/ stm/)
>
> I think some basic portability between microcontrollers is 
> useful. The
> compiler support library should be only a few 100 lines of code 
> and
> should be without external dependencies. This way it's also 
> useful for
> very small platforms (8bit) or use-cases where you inject code 
> into
> other processes. It's trivial to port: we should have an ansi-c 
> port
> and native ports should be implementable in 1-2 hours.
>
>
> The higher level library should contain stuff like 
> 'core.time.Duration',
> emplace, allocator framework, Volatile!T, register wrapper 
> types, etc.
> The implementation could be hardware specific, but it should 
> provide a
> common interface (e.g. a delay!Duration function has got a 
> common
> interface but different implementation, malloc is similar).
> Namespace micro => import micro.time; import micro.memory;
> So everything in the micro namespace is portable.
>
>
> The hardware library the provides access to hardware specific
> peripherals. In reality the high-level-library might require the
> hardware library or they could actually be merged. The 
> important part
> is portable vs platform specific module API for user code.

Sorry for the late reply, but I'm still chewing and digesting 
this.  How do you propose delegating implementation down the 
supply chain?  I suppose you may have answered that with your git 
idea below, but did you have something else in mind?

I think that's really what I'm trying to work out with this 
experiment:  How to delegate the implementation so it's obvious 
what porters need to do without a lot of explanation, and they 
can implement just the features they need.

>
> A radically different approach instead of using ports 
> directories is
> using git features: Have a base repository with a master branch 
> which
> only includes the interfaces, probably with static assert 
> wherever
> platform specific code is necessary. Then have AVR/STM32/LPC/...
> branches where you simply implement these functions. (We could 
> also
> have different repositories instead of branches)
>
> + you can modify all code
> + you already start with a common interface
> + changes are easy to compare by comparing git branches
> + changes have descriptions (in their git commits)
> + it's easy to merge further generic changes

I'll have to think about this and give it a try.  I fear, 
however, that it might be a little too radical for what people 
are used to, but maybe not.

>
> Phobos and core.stdc should then also be separate libraries.

Agreed.


>> *  Add -fno-rtti compiler switch
>
> This is something I could probably finish up in a few hours next
> weekend.

That would be an immense help and productivity boost.  Thanks for 
your support.

>
>> *  Add attribute support so programmer can choose which types 
>> to generate runtime-time info for.
>
> I can add an @attribute(notypeinfo) in GDC but it'll be 
> implemented in
> the backend. This means we can prevent TypeInfo output but we 
> can't
> reliably warn on TypeInfo usage. You'll get linker errors 
> instead.

Probably a good idea to table that for now.

Mike