[PATCH v2 REPOST] dtc: Add support for named integer constants
David Gibson
david at gibson.dropbear.id.au
Sun Jan 22 08:56:56 EST 2012
On Mon, Jan 16, 2012 at 08:41:22AM -0600, Jon Loeliger wrote:
> >
> > > 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. :-)
Well, my patch requires that expressions in cell lists have parens
around them. I think that's the only sane choice, otherwise there's
no reasonable way to distinguish between the 1 cell construct
<(500-300)> and the 2 cell construct <500 (-300)>.
> > > 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.
Right, exactly my point.
> > 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.
Right. I think my expression code and your expression code were
essentially identical syntactically (possibly modulo a slightly
different set of implemented operators).
> 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.)
True, but constant definitions (as opposed to function definitions)
would be trivial to add to my code.
> > > 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
>
--
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
More information about the devicetree-discuss
mailing list