Hitchikers Guide to Porting Phobos / D Runtime to other architectures

Johannes Pfau nospam at example.com
Wed Jan 8 07:17:31 PST 2014


Am Wed, 8 Jan 2014 12:13:33 +0000
schrieb Iain Buclaw <ibuclaw at gdcproject.org>:

> On 8 January 2014 11:13, Mike <none at none.com> wrote:
> > Can't the compiler just emit whatever the runtime provides for the
> > TypeInfo stuff, right or wrong?  So, if the runtime does not
> > provide a TypeInfo_x implementation, it doesn't emit one.  If the
> > runtime does provide a TypeInfo_x, it emits exactly what the
> > runtime provided, right or wrong.
> >
> > If the program provides a faulty TypeInfo_x implementation, the
> > program behaves in a faulty manner, just as the programmer
> > specified.
> >
> > If the program references a missing TypeInfo_x (or one of it's
> > properties) implicitly/indirectly, the linker will emit and
> > undefined reference error, won't it?
> >
> > Is this implementation possible?
> >
> >
> 
> Half and half. The TypeInfo support code is a separation layer between
> runtime and compiler and the compiler is not fully aware of what is
> implemented by runtime.
> 
> On the one hand, there's the internal TypeInfo you see in object.d,
> these are required to be known at compile time for certain operations.
>  If those aren't present then you'll get mismatch errors from the
> compiler, and in the case of GDC, a handy little ICE to end the
> compilation immediately.

However, the compiler does not actually parse and use the definitions
in object.d. It always uses it's own hardcoded definitions. So you
can't simply remove fields from the TypeInfo classes and then expect
the compiler to stop outputting the data for this field.

Although the implementation could be changed to allow for that I don't
think it's worth the trouble. I think if we can simply disable/enable
TypeInfo that should be good enough. Having many different TypeInfo
formats could bring it's own problems. 


More information about the Digitalmars-d mailing list