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/[email protected]).
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.
