Paired Nested Macroses Support

Paired Nested Macroses Support

[Dmytro Tarasiuk]

[-- Attachment #1: Type: text/plain, Size: 461 bytes --]

Good day!

Writing paired nested macros is not possible in the gas macro assembler.
For example, BEGIN/WHILE macros for loops, etc.  This is important to me
for writing portable pseudocode between different architectures that
supports gas.  I have implemented this extension since version 2.35.1
binutils and have to manually migrate it with each new stable release.
There are very few changes.  How can they be included into main code? Is it
really?

Regards.

Re: Paired Nested Macroses Support

[Jan Beulich]

On 16.02.2023 00:37, Dmytro Tarasiuk via Binutils wrote:
> Writing paired nested macros is not possible in the gas macro assembler.
> For example, BEGIN/WHILE macros for loops, etc.  This is important to me
> for writing portable pseudocode between different architectures that
> supports gas.

Without explaining (perhaps by way of providing an example) it's unclear
what you mean here.

>  I have implemented this extension since version 2.35.1
> binutils and have to manually migrate it with each new stable release.
> There are very few changes.  How can they be included into main code? Is it
> really?

Have you ever posted your patch(es)? Without you doing so, how would you
expect the code to be included in mainline gas?

Jan

Re: Paired Nested Macroses Support

[Jan Beulich]

(re-sending with the list added back - please don't drop the list when
replying to earlier list communication, unless there's a very specific
reason to do so)

On 16.02.2023 16:06, Dmytro Tarasiuk wrote:
> on, 16.02.2023 10:04 Jan Beulich <jbeulich@suse.com> wrote:
>> On 16.02.2023 00:37, Dmytro Tarasiuk via Binutils wrote:
>>> Writing paired nested macros is not possible in the gas macro assembler.
>>> For example, BEGIN/WHILE macros for loops, etc.  This is important to me
>>> for writing portable pseudocode between different architectures that
>>> supports gas.
>>
>> Without explaining (perhaps by way of providing an example) it's unclear
>> what you mean here.
>>
> 
> Excuse me. Here is an example of the macroses for nested cycles:

Thanks for the example. My first conclusion is - there's no nesting
of macros here. Instead you want multiple macros to interact with
one another in a certain way. I think this can be achieved without
patching the assembler, using alternative macro mode (.altmacro) and
the special unary % operator that this mode supports. That may
require helper macros, yes, so the set of macros overall may end up
bigger (and uglier), but that's still not necessarily a reason to
extend gas.

Furthermore ...

>     .macro DO
>         LABEL_DO\(++DO)_start:

... while this syntax may indeed have a low chance of colliding with
anything people already use (simply because it is pretty unlikely
for anyone to use two + in a row), ...

>     .endm
> 
>     .macro DO_WHILE cond
>             j\cond LABEL_DO_WHILE\@continue
>             jmp LABEL_DONE\(DO)_end

... this is a problem: There's nothing wrong with somebody having a
construct like this in an existing macro, while at the same time
also having a macro somewhere with the name DO. If you wanted to
extend the language, you would need to make sure that this cannot
break existing code.

Irrespective of the ++ being not as much of a problem syntax-wise, I
hope you're aware that without further changes elsewhere \(+ +DO)
may end up being seen as \(++DO) by the time the (scrubbed) input
reaches the parsing logic here. That's because unlike in C ++ (and
-- as well) do not form a "token"; they're always two separate +,
and hence whitespace between them may be dropped by the scrubber.

>         LABEL_DO_WHILE\@continue:
>     .endm
> 
>     .macro DONE_WHEN cond
>             j\cond LABEL_DONE\(DO)_end
>             jmp LABEL_DO\(DO)_start
>         LABEL_DONE\(DO--)_end:
>     .endm
> 
>     .macro DONE
>             jmp LABEL_DO\(DO)_start
>         LABEL_DONE\(DO--)_end:
>     .endm
> 
> Using macroses above (which is not translated without patching) I able to
> write program like below:
> 
>                 DO
>                     xor %rax, %rax
>                     mov counter, %eax

Just as an aside: The "xor" here is pointless.

Jan

Re: Paired Nested Macroses Support

[Jan Beulich]

(re-sending again, since you _again_ dropped the list from your reply;
I'm not going to further reply to private mails you may send on
technical matters)

On 16.02.2023 23:28, Dmytro Tarasiuk wrote:
> On 16.02.2023 18:31 Jan Beulich <jbeulich@suse.com> wrote:
>> (re-sending with the list added back - please don't drop the list when
>> replying to earlier list communication, unless there's a very specific
>> reason to do so)
>>
>> On 16.02.2023 16:06, Dmytro Tarasiuk wrote:
>>> on, 16.02.2023 10:04 Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 16.02.2023 00:37, Dmytro Tarasiuk via Binutils wrote:
>>>>> Writing paired nested macros is not possible in the gas macro
>> assembler.
>>>>> For example, BEGIN/WHILE macros for loops, etc.  This is important to
>> me
>>>>> for writing portable pseudocode between different architectures that
>>>>> supports gas.
>>>>
>>>> Without explaining (perhaps by way of providing an example) it's unclear
>>>> what you mean here.
>>>>
>>>
>>> Excuse me. Here is an example of the macroses for nested cycles:
>>
>> Thanks for the example. My first conclusion is - there's no nesting
>> of macros here. Instead you want multiple macros to interact with
>> one another in a certain way. I think this can be achieved without
>> patching the assembler, using alternative macro mode (.altmacro) and
>> the special unary % operator that this mode supports. That may
>> require helper macros, yes, so the set of macros overall may end up
>> bigger (and uglier), but that's still not necessarily a reason to
>> extend gas.
>>
> 
> a:
> DO
>     [...]
>     b:
>     DO
>         [...]
>     DONE_WNEN
>     [...]
> DONE
> 
> Here is shown the pair (open/close) connected with one another macroses (DO
> ... DONE_WNEN) which are nested into another pair (open/close) connected
> with one another macroses (DO .. DONE). To work correctly there must be 2
> counters: one for the sequential pairs and one for the nested pairs in each
> sequential one. These counters allow generating unique labels in each pair.
> Current macro language including altmacro features looks weak to be happy
> with it. I have paid a lot of time to find a decision. Could you show me an
> example how it is possible to do without patching even if it looks ugly?.

I'm sorry, but no, I simply lack the time to invest into putting together
something I'm never going to use.

>> Furthermore ...
>>
>>>     .macro DO
>>>         LABEL_DO\(++DO)_start:
>>
>> ... while this syntax may indeed have a low chance of colliding with
>> anything people already use (simply because it is pretty unlikely
>> for anyone to use two + in a row), ...
>>
>>>     .endm
>>>
>>>     .macro DO_WHILE cond
>>>             j\cond LABEL_DO_WHILE\@continue
>>>             jmp LABEL_DONE\(DO)_end
>>
>> ... this is a problem: There's nothing wrong with somebody having a
>> construct like this in an existing macro, while at the same time
>> also having a macro somewhere with the name DO. If you wanted to
>> extend the language, you would need to make sure that this cannot
>> break existing code.
>>
> 
> There seems to be no new problem here. Macro conflicts can be resolved by
> scope area, etc.

How is

	.macro DO
	.endm

	.macro M pfx:req, sfx:req
\pfx\(DO)\sfx:
	.endm

suddenly changing behavior not a new problem? In what you propose
nothing in M identifies that \(DO) is meant to reference DO's local
counter. Right now the DO there is substituted in literally.

Jan

Re: Paired Nested Macroses Support

[Ulf Samuelsson]

Den 2023-02-16 kl. 00:37, skrev Dmytro Tarasiuk via Binutils:
> Good day!
>
> Writing paired nested macros is not possible in the gas macro assembler.
> For example, BEGIN/WHILE macros for loops, etc.  This is important to me
> for writing portable pseudocode between different architectures that
> supports gas.  I have implemented this extension since version 2.35.1
> binutils and have to manually migrate it with each new stable release.
> There are very few changes.  How can they be included into main code? Is it
> really?

I had a similar problem myself so I started to subscribe
to the mailing list a week ago,
I explained in an "[RFC]" mail what I wanted to do with the linker.
Provided the first patchset, got some comments and reworked
the patch as well as adding to the "NEWS" file, the ld.texi for
documentation and finally added a testsuite for my new ASCIZ feature.
Nick Clifton made some small modifications and then pushed
the patch to the master branch so one week later it is part of binutils.

Working on my second patch at the moment.

Best Regards
Ulf Samuelsson

> Regards.