Re: [PATCH v2] dtc: Add support for named integer constants

On Tue, Sep 20, 2011 at 12:35:29PM -0500, Scott Wood wrote:

On 09/20/2011 03:04 AM, David Gibson wrote:

quoted

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.

I don't see it that way, but I recognize that that's a matter of
judgement on which reasonable people may disagree :).

quoted

  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

Right, this something I mean when I say no iteration 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

Hm, true.

 - 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.

That one doesn't follow, actually.  The macro can't implement a
conditional itself, but it could expand to a (constant) conditional
expression which is evaluated later.

-- 
David Gibson			| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you.  NOT _the_ _other_
				| _way_ _around_!
http://www.ozlabs.org/~dgibson