Proposal: GAS, nested structures

[Jens Bauer]

Hi Erik.

On Fri, 17 May 2013 21:32:29 +1000, Erik Christiansen wrote:
> 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.)

The GNU Assembler is an excellent assembler, no doubt. A lot of problems can be solved, but there are still areas, where it's too difficult to solve those problems.
I tried to program my way out of these problems, writing scripts that automatically generates huge header files (which have to be in sync, something I definitely despise).
So I decided to post my suggestions for how to implement 'struct'-like directives (RECORD), which has already been implemented in two assemblers (it turns out) by Apple.
One is the MPW 68K assembler, the other is the MPW PPC Assembler (two very different assemblers).

If it turns out it's a no-go to implement these in GAS, then I will need to write my own assembler (once again; I've done it before), but as some people say: "Why re-invent the wheel?"
Besides, I respect the GNU developers very much; they've all put so much work into these tools. (Are you listening, guys?) =)
I really want to avoid writing my own, if GAS can include all those features I need. -I'd rather see one fully working tool, than 300 that gets very, very close. ;)
So far, I've only encountered one nearly 'perfect' assembler; the Hisoft Devpac (aka. Gen/GenST/GenTT), but sadly, that works for 68xxx code only, and it does not have RECORD or structures. GST Assy has, however, Assy has a **very** ugly syntax.


> On 17.05.13 11:26, Jens Bauer wrote:
>> On Thu, 16 May 2013 23:22:43 +1000, Erik Christiansen wrote:
> 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.

If I went this way, I'd prefer having a 'source' for the headers, which was easy to process.
Then I would not use awk; first of all, awk is not always available, so I'd probably prefer some Perl-script.

>> 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?  :-)

Of course I will!!
Sadly, it seems that register-equates are not available for ARM. They are (more or less) available for AVR using EQU (I believe that's a feature, which was hacked into GAS; it was buggy when I used it).

> The closest I've encountered is that if we turn on .altmacro, then we
> have:
> 
> »
> `Expression results as strings'
>      You can write `%EXPR' to evaluate the expression EXPR and use the
>      result as a string.
> «

Thank you very much for this hint. I'll try and look at it; this may solve a lot of problems.

One thing I didn't think of, is if Texas Instruments made the source for their modified GAS available.
-They probably did. Some of their features look interesting and are perhaps worth porting back into the official GAS.

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

I've always lived in a different world: If my tools lack a function, I write my own.
That slows me down, but on the positive side, I learn a lot about how the tools work and why. ;)

>> 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
> 2/(7*10^9).

You forgot the Apple's. ;)
-Besides... There *are* developers that use .struct, besides you and me; searching the net reveals many users.
But I'm afraid the benefit from using .struct is too little, compared with how difficult it is to find documentation on what it can do.
(I've learned from searching the net, trying out examples and suggestions, just to find out that 50% of what I tried didn't work - because some people probably use a modified version).

Remember: The ARM community is growing. Almost everyone wants a gadget with a LCD-display and an ARM-chip inside (Phones, tablets, etc.), and I see that the interest in ARM-assembly language is growing.
Also: There are a lot of guys who write assembler for other chip types than AVR and ARM. -Intel, PowerPC, 68K, MIPS, etc.
-They will all benefit from having a 'RECORD' directive with friends. =)
I see that microcontroller manufacturers (including ARM, which is not a manufacturer), would start writing header-files, which can be included both from assembler and C.
Atmel already does it to a degree. (I do it myself). My include-files can be included by both .include (GAS), #include (GAS with PP) and #include (C).


Love
Jens