April 18, 2011 D target "layers" (was: D Cross Compiler) | ||||
---|---|---|---|---|
| ||||
On 19/04/2011 5:00 AM, d.gnu-request@puremagic.com wrote: > From: Daniel Green<venix1@gmail.com> > On 4/18/2011 5:15 AM, Kagamin wrote: >> > Such feature would be fantastic. > I don't see this becoming a feature of D for quite some time if ever > although it would make the enforcement easier. > Once the subsets are defined the next challenge is enforcing them. Two > ideas come to me right now. Enforcing it by checking object symbols, > most restrictions would generate some form of standardized symbol > request. The other is to use the D frontend and create a sort of lint > checker. I envisage a compiler switch to tell the compiler the target "layer" -- bare, kernel, driver-low, driver-high, user ?? The compiler would then produce a warning or error if certain language or run-time features are being used that is not suitable for the target layer. Maybe it can be a flexible system rather than hard coded into the compiler, such that there are config files that specify which language features are permissible or not. e.g. --target=bare, --target=kernel, --target=my-custom-target (where my-custom-target[.cfg] is a file in standard location or filename) --target=~/D/configs/my-custom-target.cfg ??? I'm sure the XOmB guys/gals (which I'm sure lurk on the various D lists) would have some good ideas and thoughts on this too. Just thinking out loud :) -- Brendan. |
April 18, 2011 Re: D target "layers" (was: D Cross Compiler) | ||||
---|---|---|---|---|
| ||||
Posted in reply to Brendan Simon (eTRIX) | == Quote from Brendan Simon (eTRIX) (brendan.simon@etrix.com.au)'s article
> On 19/04/2011 5:00 AM, d.gnu-request@puremagic.com wrote:
> > From: Daniel Green<venix1@gmail.com>
> > On 4/18/2011 5:15 AM, Kagamin wrote:
> >> > Such feature would be fantastic.
> > I don't see this becoming a feature of D for quite some time if ever
> > although it would make the enforcement easier.
> > Once the subsets are defined the next challenge is enforcing them. Two
> > ideas come to me right now. Enforcing it by checking object symbols,
> > most restrictions would generate some form of standardized symbol
> > request. The other is to use the D frontend and create a sort of lint
> > checker.
> I envisage a compiler switch to tell the compiler the target "layer" --
> bare, kernel, driver-low, driver-high, user ??
> The compiler would then produce a warning or error if certain language
> or run-time features are being used that is not suitable for the target
> layer.
> Maybe it can be a flexible system rather than hard coded into the
> compiler, such that there are config files that specify which language
> features are permissible or not.
> e.g. --target=bare, --target=kernel, --target=my-custom-target (where
> my-custom-target[.cfg] is a file in standard location or filename)
> --target=~/D/configs/my-custom-target.cfg ???
> I'm sure the XOmB guys/gals (which I'm sure lurk on the various D lists)
> would have some good ideas and thoughts on this too.
> Just thinking out loud :)
> -- Brendan.
GCC already provides such equivalent options:
-fhosted - Assert that compilation takes place in a hosted environment in which the entire standard library is available. (reverse is -fno-hosted)
-ffreestanding - Assert that compilation takes place in a freestanding environment in which the standard library may not exist, and program startup may not necessarily be at "main". (reverse is -fno-freestanding)
|
Copyright © 1999-2021 by the D Language Foundation