This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Proposal: GAS, nested structures

Hi Jens,

I'm running out of suggestions, but there's just one more which might be
of some use, once you figure out how to use it. (Oh, and also a hack ...
that's often the most convenient way out of a dilemma, so long as we
don't admit to doing it.)

On 17.05.13 11:26, Jens Bauer wrote:
> On Thu, 16 May 2013 23:22:43 +1000, Erik Christiansen wrote:
> > Now ldd  r16, Y + mystruct.that_element
> > 
> > provides the per-struct namespace for elements.
> This is true, it's good and gets us a long way, but... It's not really
> easy to create a 'readable' header-file, which can be shared between
> both C and assembler this way.

Okaaaay ... then I'd code the struct in C, solving half the interworking
problem, and all of the readability issue, then fling together a few
lines of awk to read the C, and spit out .struct statements to
auto-replicate the thing in assembler. That seems to satisfy the
inviolable rule of coding stuff in one place only. ('Cos ya can't trust
humans, not even the one sitting in your seat.) Isolate the structs in a
header, and the awk script can be slightly simpler.

Handling of simple structs, and arrays of structs, seems simple enough,
off the top of my head. Nesting might need sneaking up on.

> It would help, though, if one could, like the '.set' directive, assign
> string values to symbols, and then use those symbol values to
> concatenate structure names. I haven't found out if this is possible,
> though. I can use .ifc, .ifnc, .ifeqs, .ifnes to compare strings, but
> haven't found out if it's possible to assign strings to symbols yet.

If you do find a well documented way, you will share?  :-)

The closest I've encountered is that if we turn on .altmacro, then we

`Expression results as strings'
     You can write `%EXPR' to evaluate the expression EXPR and use the
     result as a string.

Since only integer and empty expressions are documented, AFAICT, there
seems to be a distinct lack of any string operators to make this useful.
(Leaving us with only simple concatenation, implicit or "&"/"\()"
assisted, which we're already using.)

A quick scan of /usr/local/src/binutils-2.23/gas/expr.c 

and /usr/local/src/binutils-2.23/gas/bfin-parse.c showed both '%' and a
PERCENT token, but only integer-related operations. In the BNF grammar,
/usr/local/src/binutils-2.23/gas/config/bfin-parse.y, I've only stumbled
across the rule:

   | expr_1 PERCENT expr_1

None of it leads me to a lot of string-ish %EXPR, even chasing the
EXPR token as well. (I'm not sure that greater persistence would yield a
lot of reward.)

> >> 3: While we're at it, it might make sense to include unions in my proposal.
> > 
> > Well, that's just alternatives with the same start address, I figure.
> > Off the top of my head it looks easier than nesting.
> The reason I'm mentioning unions now, is that they're in "struct's
> family" and thus can be part of a nested struct. Eg. they would have
> 'membership' of a struct, structs would have 'membership' of unions,
> etc.

Errr ... I'm acutely reminded of my preference for solving today's
problems today. (Then finding out what's for lunch.)


> In other words: If it's flexible and easy to use, it will be used by more people. ;)

We-ell, more than if it's not, but still not necessarily many at all, I
fear. You have to catch 'em young. Once familiarity is gained with
something that "does the job", even if you have to whack it with a stick
to do so, it'll retain favour, because of the cost of a new learning
curve ... regardless of what's at the end of the rainbow.

The global interest level in hand-crafted assembler structs may be just


Habit is habit, and not to be flung out of the window by any man, but
coaxed down-stairs a step at a time.
                          - Mark Twain, "Pudd'nhead Wilson's Calendar

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]