Building LDC runtime for a microcontroller

Adam D. Ruppe destructionator at gmail.com
Fri Sep 18 23:00:33 UTC 2020


On Thursday, 17 September 2020 at 09:53:57 UTC, Remi wrote:
> My problem here is mostly understanding the __initZ symbol and 
> where it comes from.

The compiler generates that when it spits out something that uses 
TypeInfo, which is a lot of things: ~= and ~ operators on built 
in arrays, the new operator, class dynamic casting, exception 
catching, and more. Annoyingly, even having a class member of a 
type will trigger a TypeInfo dependency too. Why? idk, probably 
to do with precise GC hook support.

The error you mentioned in your other message about the order of 
files is interesting.. I suspect that is because the compiler 
creates these symbols when it first sees a need... then tries to 
reuse it, and that must have made the conflict here since it made 
it in the wrong context... or something.

The error says something about constness being different, well, 
why the eff would an init symbol ever be mutable? And ldc is so 
strict about this stuff too where dmd just doesn't care and that 
can be annoying too.

idk this probably doesn't help you much since I don't know why it 
is generating it this way either. It is possible it is actually 
pulling the definition from the original druntime or something.

(on my webassembly.arsdnet.net site btw I made my own little 
on-demand build web service to pass the right args. p convenient 
but also specialized for me and prolly not too general purpose)

I'll keep investigating as I have time, but I do kinda prefer th 
idea of improving the system rather than hacking around it lol

> I'll probably try what you describe in your "Zero-runtime 
> classes" actually, and hopefully I can get away without the 
> string manipulation or replace it with my own version of it.

oh the string manip there is just looking up the symbol, it isn't 
too bad.

The betterC thing also kinda sorta works with classes btw if you 
combine this with extern(C++) class definitions.


More information about the Digitalmars-d-learn mailing list