Hitchikers Guide to Porting Phobos / D Runtime to other architectures

[Mike]

On Wednesday, 8 January 2014 at 15:05:56 UTC, Johannes Pfau wrote:
> I think there are three steps to make TypeInfo completely 
> optional
>
> * -fno-typeinfo as a global switch instructing the compiler 
> that it
>   _never_ has typeinfo and should never output typeinfo. In 
> this case
>   all files must be compiled consistently with -fno-typeinfo or 
> without
>   it
>   Useful to disable all TypeInfo generation even if the runtime 
> has
>   typeinfo support
> * pragma(notypeinfo)/@attribute(notypeinfo) as in LDC
>   Useful to exclude typeinfo for specific types
> * A way for the runtime to say 'I don't support TypeInfo'
>   Basically introducing 'core.config' with 'enum
>   RuntimeSupportsTypeInfo = false;'. If the compiler finds this
>   declaration it should automatically use '-fno-typeinfo'

This has been an interesting discussion, and has cause me to come 
full circle with a different perspective.

First, I want to dispell a potential myth:  "If we don't elminate 
TypeInfo stuff we'll have code bloat"
This is not true if compiling with -ffunction-section, 
-fdata-sections, and linking with --gc-sections.  All the 
TypeInfo stuff will eventually just get stripped out by the 
linker, as long as it's not used by the program.  However, the 
compilers will have to generated code that can be safely --gc'ed. 
  GDC, at the moment, doesn't.  I need to minimize my code and 
report an issue on this.  It's first on my list, so please stand 
by.  Discussion here 
(http://forum.dlang.org/post/wrekpqefiswstqhhrhoh@forum.dlang.org).

As long as the TypeInfo and other unused stuff can be safely 
--gc'd, D will be suitable for the tiniest of microcontrollers.

"So what's the problem?", you might ask.
The problem is really convenience.  I want to make a simple 
10-line "Hello World" with a struct containing 1 measly property, 
and I have to create 1000 lines of runtime stuff just to get it 
to compile.  And worst of all, none of that runtime stuff has any 
hope of every being called, and --gc-sections discards it anyway. 
  How unfortunate!

Actually, for the aforementioned contrived example, it's only 
about 150 lines in GDC at the moment, but LDC appears to be much 
more (LDC folks, I'll make an issue report soon.  It's second on 
my list).

So, why would one want to make a "Hello Word" program with a 
single struct containing 1 measly property?  Answer: to learn.  
But in the end, after one learns the runtime and adds all of the 
features they want, what will the end up with?... A 10,000 line 
runtime with all the TypeInfo stuff and more...and they'll be 
really happy with it.  And worst of all, the -fno-typeinfo switch 
that they were using while they were learning, was removed from 
their makefile in the first month of study.

"So, what's the REAL problem?", you might ask.
Answer: Lack of information about the runtime. e.g. no porting 
guide and a tightly-coupled hairball of d runtime with very 
little modularity, and very little platform, hardware, and 
feature abstraction.  I now think that parts of this current 
conversation would not even exist had this information existed.

There doesn't seem to be much interest from the runtime folks in 
doing something about this, so I intend to.  The porting guide is 
3rd on my list.  And it's going to stink, because I don't know 
what I'm doing yet.  But maybe people irritated by the smell will 
help clean it up.

I think the -fno-typeinfo switch and the other proposed changes 
will be quite useful for the student of D and the D runtime, but 
I think they will only be used temporarily in their initial 
study.  I'm not voting against it, but I'm beginning to see it as 
not-so-important.  Maybe others have different needs for it than 
I, and it may be useful to them.

I'm quite thankful however, for the engligtening discussion, and 
the willingness to be so accomodating.  Thank you!

>> I think the best logical steps to go down, is that you should 
>> write a
>> replacement for the core library functions that the compiler
>> implicitly calls (_d_arrayliteralX, _d_arraycopy, _d_newclass,
>> _d_newitemT, etc), but omit using the TypeInfo parameter.  
>> Once you
>> feel that it is ready, then we can add a switch into the 
>> compiler
>> that:
>> 1) Doesn't generate typeinfo
>> 2) Passes a null pointer as the typeinfo parameter to the 
>> Druntime
>> library calls.
>> 
>
>> Object _d_newclass(const ClassInfo ci)  ->  Object 
>> _d_newclass()
>> 
> IIRC Andrei wants _d_newclass to be independent of ClassInfo 
> anyway (by
> making it a template). I think this came up when we talked about
> replacing 'new' with a library template or in a custom allocator
> discussion or something.

A templated _d_newclass, and possibly other runtime hooks would 
help greatly with the tight-coupling of the runtime.  It's not 
fourth on my list, yet, but it could use an issue report.