Re: Proposal: GAS, nested structures

[Jens Bauer <jens at plustv dot dk>]

Hi Erik.

On Thu, 16 May 2013 23:22:43 +1000, Erik Christiansen wrote:
> On 16.05.13 00:28, Jens Bauer wrote:
>> As for myself, I made RSRESET, RSSET, RS.B, RS.H, RS.L macros; these
>> do not require sections, as they're only based upon .equ; but this can
>> not solve my issue.
> 
> They need more work then ... perseverance ... drive ... insight and toil.
> (E.g. Does the namespace tweak, outlined in this post, help?)

Yes, the namespace tweak does help. I have done similar already.

I can still (manually) do...
                RSSET   0
                RS.H    cat.origin.x,1
                RS.H    cat.origin.y,1
                RS.H    cat.size.width,1
                RS.H    cat.size.height,1
                ...

-But currently, I can't see that it would be possible to solve the issue(s) mentioned with simple ('flat') structures.
Besides, it does not allow me to refer to 'x' alone and it's also starting to look messy.

Still... This is not about "my" problems and not about 'ranting' either. ;)
It's about making life easier for a large group of assembly-language programmers and improving an excellent tool.
Although I'm interested in ARM assembly, people on many different platforms would benefit from having these features. =)

>>> What was it you found didn't work?
>> It works fine, I do not have any problems getting it to work as expected.
>> The reason for my post is mainly:
>> 1: Make it possible to nest structures
>> 2: Most important of all: Allow identical member names in multiple 
>> structures, eg.
>>    struct Dog { uint16_t legs; uint16_t heads; uint16_t tails; };
>>    struct Bird {uint16_t legs; uint16_t wings; uint16_t heads; };
> 
> Ah, yes, point 2 offers challenges. (Is it possible that it's time to
> retreat to C once we're into that level of complexity?)

Impossible, because I need the assembler, so that I can rely on my code being clock-cycle accurate and instruction-size accurate.
Any C-compiler is free to insert prologues, epilogues, popcorn and candies or even removing code as they wish.
I'd rather just use plain hex-offsets than retreating to C. Believe me: I do not want to use hex-offsets.

> We can modify the "element" macro:
> 
>    .altmacro                  ; Allows '&' instead of "\()" separator.
> 
>    .macro element struct elem size     ; Struct ID added.
> \struct&.\elem:                        ; Element name compounded.
>    .struct \struct.\elem + \size
>    struct_size = struct_size + \size
>    .endm
> 
> 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.

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.

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

One more thing I forgot, is that the MPW assembler had a feature that could 'open' a record, so you wouldn't have to type the entire "struct name", eg.

Normally you'd write...
        ldrh    r1,[r0,#TextBox.origin.x]
        ldrh    r2,[r0,#TextBox.origin.y]
        ldrh    r3,[r0,#TextBox.size.width]
        ldrh    r4,[r0,#TextBox.size.height]
...but instead you could write...
        WITH    TextBox
        WITH    TextBox.origin
        WITH    TextBox.size
        ldrh    r1,[r0,#x]
        ldrh    r2,[r0,#y]
        ldrh    r2,[r0,#width]
        ldrh    r2,[r0,#height]
...You can use WITH, when you know, that your structure members names do not conflict with member names used in other active structures.
But let's assume we need to use two structures, that have conflicting member names from the same assembler file:
        WITH    Dog
        ldrh    r2,[r0,#legs]
        ldrh    r3,[r0,#heads]
        ...
        WITHOUT Dog
	 	WITH    Bird
        ldrh    r4,[r1,#legs]
        ldrh    r5,[r1,#heads]
...Of course, for only accessing a few members, it won't pay to use WITH (except from if you're using macros to access the members).

It might be possible to add a second parameter to 'WITH'; a register, so that each time a member of this structure was used with that register, this structure would automatically be chosen:
        WITH    Dog,r0
        WITH    Bird,r1
        ldrh    r2,[r0,#legs]
        ldrh    r3,[r0,#heads]
        ldrh    r4,[r1,#legs]
        ldrh    r5,[r1,#heads]

Another assembler I used, had the ability to attach a register to a structure, so each time you used...
        move.w  d0,struct_member
...it would automatically change it to...
        move.w  d0,struct_member(a5)
...but I don't recall which assembler that was (could still be MPW, though).
One problem with this, was that the structure could only be used with *that* register; the register could not be changed.
This was due to that the register was attached to the structure itself, it wasn't attached by a separate directive.
But a possible implementation could be like this...
        ASSIGN   r0,Dog
        ASSIGN   r0,Mood
        ldrh     r2,[#legs]
        ldrh     r3,[#heads]
        UNASSIGN r0
        ASSIGN   Bird,r1
        ldrh     r4,[#legs]
        ldrh     r5,[#heads]

(or to just unassign r0 from Dog, one could write UNASSIGN r0,Dog - so the second parameter is optional).

Having tried the 'RECORD' feature in the old MPW Assembler, you really want to have this feature in any assembler.
Again; if implementing this functionality, I'd like to put my ideas and as many thoughts on the table as possible, so the record/struct/union features will become as flexible and usable as possible. ;)
What I'm proposing is something that opens up possibilities while it shortens the source code, gives better overview and encourages those people who write header-files, to add support for assembly language.
Atmel is already making headerfiles for AVR assembler, but... when you move to ARM, you really, really wish they had supplied include files for assembler.
Unfortunately you need to write them all from scratch yourself, so does other people, if you don't share your work.
In other words: If it's flexible and easy to use, it will be used by more people. ;)


Love
Jens