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

[Mitch Bradley]

I find it ironic that the very first device tree implementation, dating 
back to 1989, was built around a Turing complete language.

On 1/11/2012 11:36 AM, Stephen Warren wrote:
> Jon Loeliger wrote at Wednesday, January 11, 2012 7:38 AM:
>>> On Tue, Jan 10, 2012 at 01:54:30PM -0800, Stephen Warren wrote:
>>>> John, David,
>>>>
>>>> What can we do to reach consensus on expanding dtc to handle named
>>>> constants, or in general any future direction to extend the syntax with
>>>> expressions etc.?
>>>
>>> Hrm, so, I'm not at all keen to add a named constant syntax without at
>>> least having an outline of what a future macro/function syntax would
>>> look like.
>>
>> Which is where I thought it was left earlier...? :-)
>> And it's not just what the macro/function syntax will look like,
>> but also how these will play into a more generalized expression
>> handling mechanism.  Defining something one-off now that doesn't
>> fit well into a long term plan is less than ideal.
>>
>> Yes, I know that is tantamount to requiring the whole, larger
>> picture be solved first.  But Dave is right -- at least an outline
>> of the direction.  Seriously, the lexical problems can form some
>> of the nastiest gotchas if we're not careful from the onset.
>
> So that all makes sense.
>
> My question is: How can we get consensus on what we want that complete
> future syntax to be? IIRC, Jon has a branch that implements a proposal,
> and David at least posted a different proposal if not actual code that
> implemented it. We're not missing proposals, but rather a mechanism to
> decide between them?
>
> For what it's worth, I'd tend towards a simple expression-based syntax
> where property values can be calculated with C-style expressions. Basic
> math stuff like ( ) + - * /&  | ~<<  >>  and some basic string handling
> operations (str(int) and concatenation). I think that'd cover the vast
> majority of use-cases wouldn't it? For more advanced stuff like loops
> to synthesize multiple nodes, it seems like writing a custom script to
> generate the .dts file and then passing the result to dtc would be more
> modular, and not require us to create a whole new Turing-complete
> language in dtc?
>