Re: Proposal: GAS, nested structures

[Erik Christiansen <dvalin at internode dot on dot net>]

On 15.05.13 07:59, Jens Bauer wrote:
> .struct can be implemented by using macros, so it's not really "really
> needed".

True, but my home-baked macro implementation from about 13 years ago
gave errors with current gas versions, when I tried it last week. So I
moved to using .struct, despite the absence of documentation. It was
easier to use what's there, than grump about my petunias having been run
over.

> Also, it's difficult to find documentation on how to use it.

In my experience, it usually takes only minutes to figure out (to a
first approximation) how individual undocumented gas capabilities
behave, so the lack of documentation is not practically significant.
I've just assumed that it works in a reasonable way, tried variations
until the errors go away, and the objdump or .lst output is to my
satisfaction. Job done, time for coffee, and it is quicker than
writing long emails.

[Guff about how they used to make cheese in the Old Country elided.
 Guff about how cheese should be made here, so that it would be just
 like in the Old Country, scanned but not read.]

If you were to post here a .struct which is not working for you, then it
would be possible to try to offer advice. I have only made a simple
.struct, using a couple of macros to make life easier. In the absence of
real-world input from your side, I will offer that first attempt at this
method. (Disclaimer: There may be better ways.)

The source code:

   .section .bss,"aw"

   struct
   element key 1         ; Key number
   element row 1         ; Row number
   element count 1       ; Keypress validation
   element old_state 2   ; For SDL subroutines.
   end_struct keyb_data

uses these macros:

   .macro struct                          ; Begin declaration of array of structs.
   .struct 0
   struct_size = 0
   .endm                                  ; (See end_struct macro)

   .macro element elem size               ; Declare a struct element.
\elem:
   .struct \elem + \size
   struct_size = struct_size + \size
   .endm
   
   .macro end_struct name rpt=1
   sizeof_\name = struct_size * \rpt      ; Size of the (array of) struct(s).
   numof_\name = \rpt                     ; Number of structs in the array.
   .section .bss,"aw"
\name: .space sizeof_\name                ; Create storage for name[rpt]
   .endm

Clearly, there is redundancy in the use of .section directives, but I
only tried this stuff out one evening last week. (And one of them can
serve as documentation.)

After linking, the struct is created here:
 .bss           0x00800229        0x5 keyboard.o
                0x00800229                keyb_data

And correct addressing of e.g. keyb_data.count is shown in this avr-objdump:

00000322 <VALIDATE>:
...
 33e: 8a 81          ldd   r24, Y+2 ; 0x02

of the sourcecode snippet:

state VALIDATE
...
1:    ldd r24,Y+count

What was it you found didn't work?

That doco guff you found, referring to "absolute section" also put me
off for several seconds, before I concluded that it was not an obstacle
- the struct would go into my chosen section, with just the struct
offsets having to be immune to relocations. The text seems primarily a
warning that the user must set the desired section before attempting to
e.g start adding code. Looking at the above example, that seems to work
for me. (So far. ;-)

If we wanted to be able to use the macros in the middle of code, then a
.pushsection in the "struct" macro, and a .popsection in end_struct
would get us back out of the absolute section without fuss.

Best of luck.

Erik

-- 
In a time of drastic change it is the learners who survive; the               
'learned' find themselves fully equipped to live in a world that no          
longer exists.                                     -  Eric Hoffer