From mboxrd@z Thu Jan 1 00:00:00 1970 From: Scott Wood Subject: Re: [PATCH v2] dtc: Add support for named integer constants Date: Tue, 20 Sep 2011 12:35:29 -0500 Message-ID: <4E78CEE1.3090403@freescale.com> References: <1314739818-13904-1-git-send-email-swarren@nvidia.com> <74CDBE0F657A3D45AFBB94109FB122FF04B327A62D@HQMAIL01.nvidia.com> <20110908183211.GM2967@ponder.secretlab.ca> <20110909013433.GC21002@yookeroo.fritz.box> <74CDBE0F657A3D45AFBB94109FB122FF04B732144F@HQMAIL01.nvidia.com> <20110920080409.GL29197@yookeroo.fritz.box> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20110920080409.GL29197-787xzQ0H9iQXU02nzanrWNbf9cGiqdzd@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org To: David Gibson Cc: "devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org" List-Id: devicetree@vger.kernel.org On 09/20/2011 03:04 AM, David Gibson wrote: > So, there are basically two approaches to macro or function support. > > A) Functions > > We allow definition of functions with parameters. These are stored > in some kind of parse tree representation in a symbol table. Instead > of producing a more-or-less fully realised device tree as we parse, we > produce some kind of parse tree showing the expressions and function > calls. After parsing is complete we make another pass evaluating all > the expressions and functions. > > Advantages: > * Allows repeats / iteration to be done simply. > * Potentially allows superior type and other error reporting > * Jon already has a prototype in the test branch > > Disadvantages: > * Requires a substantial runtime evaluation infrastructure to be > implemented, including representation and storage of function > definitions. > * I don't like Jon's proposed syntax in the test branch because > although it's C like, it's very much against the current > declarative feel of dts. That is, it feels somewhat like a program > that's executed to produce the device tree rather than a > representation of the device tree itself You could say the same thing about macros. This is just doing it at a higher semantic level. > Disadvantages: > * The # used for preprocessor directives clashes with common > property names beginning with #. In practice this can be > disambiguated by assuming only # in column 0 is for cpp, but the > options to make cpp behave this way are not necessarily portable. There are other disadvantages, namely that cpp, while familiar, is not a very good macro language: - No recursive macro expansion ("self-referential" in cpp's terms) -- useful for iteration in the absence of explicit support - No conditionals inside the macro body -- needed to make recursive macros work, but also useful on their own - Awkward handling of multi-line macro bodies -- backslashes everywhere, and makes it difficult/awkward to fix the previous issues with incremental extensions of the macro language - Does not integrate well with the surrounding language's indentation/formatting, especially if the directives need to be in column 0 If we're going to use an existing macro language, something more like the GNU assembler's macros would be nicer. Another disadvantage of any approach that tries to separate macros from the underlying language is that you can't have anything be conditional on an expression that the macro layer doesn't understand. -Scott