"BareBones" VersionCondition identifier for druntime
via Digitalmars-d
digitalmars-d at puremagic.com
Sun Oct 19 00:49:06 PDT 2014
On Friday, 17 October 2014 at 19:04:59 UTC, Kevin Lamonte wrote:
> * "Affirmative" definitions: BareMetal, Baseline -- a short
> list of "these features/functions are the absolute minimum
> required to support D2 syntax, after which one could build the
> rest".
>
> * "Negative" definitions: NoLibC, NoThreads, NoGC --
> "everything currently in druntime minus these things".
Sounds to me like the "nogc" check should be generalized so that
libraries state what features they use or assume, per function or
per module. I think the language should enforce it, so that you
on the module level you state what features you use, and then
turn off features on a class/struct/function level.
The runtime should provide a meta-level description of what it
supports and also optionally contain version blocks that strips
it down.
This gives the following process for whole-program compilation:
1. Compiler loads a manifest file for the project with additional
configuration information and statistical information for
function calls, memory allocation dynamics etc.
2. Compiler search through the user code and records what
features are being used (like it should do for nogc) and also
additional probabilistic information. Compiler checks that the
requirements from the manifest are satisfied.
3. Compiler compiles the runtime with the meta-information from
(1) and (2) and the runtime CTFE can do whatever it wants with it.
4. Compiler compiles the rest of the program and can inline
"reduced" runtime-parts where they make sense.
It makes a lot of sense to provide non-application code with
extra information that can be used to tune the code and you are
quite right that you need to define a set of meaningful
descriptors.
I don't think "BareBones" would be the best solution. I think
libraries/runtime could deduce that from more fine-grained
information, and you could have CTFE libraries that computes
those values for you.
I also don't think this should be specific just for the runtime,
it is relevant for all reusable code that is written
independently from the application.
It might also be nice to have a way to generate C-header files
with the same meta information so that you can configure C-code
through the same means. And in the long run perhaps even modify
an existing C-compiler to provide the D-compiler with information
about the C-code too (like escape analysis).
More information about the Digitalmars-d
mailing list