"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