Hitchikers Guide to Porting Phobos / D Runtime to other architectures

[Johannes Pfau]

Am Wed, 8 Jan 2014 01:15:32 +0000
schrieb Iain Buclaw <ibuclaw at gdcproject.org>:

> 
> If you use a struct, it generates typeinfo and initialiser symbols
> that go on the comdat on the basis that you *may* access the typeinfo
> at runtime.
> 
> These are weak decls so the linker merges/removes duplicates.  There's
> currently no solution in which the compiler decides whether to omit
> sending the symbols to object file, but this can be worked upon.

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'

'core.config' could then also be used with RuntimeSupportsGC,
RuntimeSupportsUTF (switches over strings, IIRC) and similar things. A
minimal runtime would just set all those variables to false and the
compiler could automatically use a restricted set of D (nogc/no string
switches/...)

> 
> 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.

There were already approaches making associative arrays a templated
library type. Then we could just as well make normal arrays a templated
library type and avoid typeinfo there.

Runtime variadic arguments need typeinfo IIRC. We'd have to ban calling
those functions with -fno-typeinfo or if any of the arguments was
declared with @attribute(notypeinfo)