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

[Jon Loeliger]

> 
> > 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 applying that would be reasonably safe as it is.  If we go
> with Jon's proposal or something like it in the end, we'll need to
> reimplement most of the expression evaluation (to do delayed instead
> of parse-time evaluation).  But I'm much less worried about having to
> rework code - even substantially - than I am about user-visible syntax
> regressions.

Even with that piece, there are substanial lexical and parsing
issues that complicate things.  Bare numbers, or expressions,
next to each other without syntactic glue can cause parsing fits. :-)

> > I think that'd cover the vast
> > majority of use-cases wouldn't it?
> 
> Not quite.  Expressions are interesting of themselves, but not all
> that useful.  It's functions or macros plus expressions which gets us
> close to where we want to be.  So expressions gives a little as it is,

That's the difficult and slippery slope here.  Being able to write
    (FOO << (12 + 2))
is nice, but it would be nicer and more useful to represent
    (FOO << ((i) + 2))
where (i) was actually parameterized or iterated in some way.

> a lot more for people already running their dts through cpp.  To
> really make progress, we still want a proposal for a standard function
> or macro syntax for dtc.  And, obviously, a decision whether to go
> with functions or macros.  I like macros, because I think they give a
> lot of flexibility with minimal conceptual complexity.  Jon's proposal
> is based on functions.  I didn't like his proposal very much as a
> whole, but I should take another look and see what I think of the
> function syntax in isolation.

It might also be instructive to isolate my expression parsing
for its lexical and syntactic changes and work towards introducing
those, perhaps in isolation, as a first step.

The key there WRT your interest, Stephen, is that it can capture
the use of apparent variables or #define'd-equivalent symbols within
the expression handling.  (David's version did not.)

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

OK.  Let's explore that approach.  We'll write a, say, Python collection
of code-objects for each, what?, device.  Place them all in a large library.
Your "device tree source" effectively now becomes a "main" that starts
instantiating librarified devices, adding a litle glue to emit some
one-off property or two.

That could work.  But is it now OK that the construction of the device
tree source file is tied to Python?  Do we make the kernel builds now
reliant upon Python too?  Or Perl?  But wasn't that shot down *again*?
Hans wants shell.  Lotte likes Lua.  Suki plays with Python.  Willi
is happy again.  Adolf builds his DTS with Perl.  No one uses Tcl.
Everyone just checks-in their *generated* DTS results anyway.  It'll
be a war without tears.

Or how do you see this working?

> .. One of the reasons that I'm so doggedly conservative and
> picky about new dtc syntax is that small languages have a tendency to
> grow to Turing completeness, whether you intend it originally or not.

Isn't that someone's observation...?  Behind every flat-file there is
a Turing-complete language trying to get out.

> I'm ok with that happening, but I'd really like to make sure that when
> and if it happens, we arrive at a decent Turing complete language, not
> a horrible one.

Name two decent ones. :-)  C and ..., and ....  See?  There isn't another!

Never mind.

jdl