What is the state of Microcontroller support in d?

[Iain Buclaw via Digitalmars-d]

On Wednesday, 21 June 2017 at 00:08:24 UTC, Mike wrote:
>
> GDC may have fixed the problem recently with [2], but I haven't 
> tested it.  Lucia Cojocaru is (was?) also working on addressing 
> the problem by lowering TypeInfo calls in the compiler to 
> templates [3].
>

I've decoupled the code generating compiler (gdc) from runtime 
(druntime), and will generate pseudo typeinfo if any are missing 
- this is in contrast to dmd which would complain about missing 
TypeInfo/corrupt object.d.

This should mean that object.d can be distilled down to just:

   module object;
   class Object { }

 From a minilibd perspective, and the compiler will just fill in 
the blanks and continue without complaint.  However you'll still 
get linker errors if you don't define TypeInfo anywhere.  (If 
there are any other compile-time errors, it's likely the dmd 
front-end complaining because it can't generate some artificial 
helper function).

Pay-as-you-go TypeInfo generation could be done stemming from 
this.  Currently, the strategy is to always generate TypeInfo in 
the module that "owns" the type, on premise that although it may 
not be used itself, some external module may want it.

Really though, this is probably about as far as I can push it 
without making changes to the dmd frontend or druntime library 
itself.  IMO the right thing to do is to not push the compiler, 
but to push the D runtime library into improving it's runtime 
interface.

i.e: https://github.com/dlang/druntime/pull/1792

Replacing the old legacy functions with templates that don't 
require typeinfo is the direction that people should be pushing 
in.  Without this, I can't see -fno-rtti being possible without 
severely restricting users to a slim subset.

Regards,
Iain.